feat(modules): a third slot, nav icons, and api.BASE (phase 3, slice 3)

The three things core owes the client half before it can leave, all additive,
all MODULE_API 1.2.0 → 1.3.0.

`player.invite.accepted` is the third extension slot. Core's invite page owned a
UO game-account step — it read a `gameAccountSignup` flag out of core's own
settings and posted to a shard route — and an invite is a core concept that
staff receive too, so the page stays and its optional next step becomes a slot.
Named for the place, like the other two. Whether there is a step at all is the
filling module's call, made from data core does not have; core keeps the shell,
the skip control and the destination.

`icon` on a nav item, because without it the six extracted UO rows would have
been the only text-only entries in a sidebar where every other row has a glyph.
Core supplies no fallback — an invented one is core making a presentation choice
for content it knows nothing about. `icon` was already among the fields an
override may not touch, so the concept predates a module being able to send one.

`api.BASE` was in §3.5 from the first draft and never actually published.
`request` is fetch-only, so an EventSource builds its own URL, and the shard's
live feed is two of them; the alternative is a module hardcoding `/api/v1`,
which asserts something about core that core has not promised.

`AcceptInvite` is the one legitimate reader of `extensionFor` outside Slot.jsx:
the answer decides a NAVIGATION, not a decoration. Decoration goes inside
`<Slot wrap>`, which is why `hasExtension` stayed deleted.

Co-Authored-By: Claude <noreply@anthropic.com>

client/src/modules/version.js

@@ -11,6 +11,12 @@
 // that the two files can drift, so a test asserts they agree
 // (client/test/moduleRegistry.test.js) rather than trusting a bump to remember
 // both.
+// 1.3.0 — three additions, all from Phase 3 slice 3 needing them: a nav item may
+// carry an `icon` component (§3.3), core declares a third slot
+// `player.invite.accepted` (§3.7), and `window.__rg.api` gained `BASE`, which
+// §3.5 always documented and shared.js never published. Additive throughout: a
+// module written against 1.2.0 is unaffected. The server half is untouched and
+// bumps anyway, for the reason below.
 // 1.2.0 — `registry` gained `registerExtension` and core gained extension slots
 // (MODULE_API.md §3.7). The first change to window.__rg since 1.0.0, and an
 // addition: a module that never fills a slot is unaffected. The server half is
@@ -20,4 +26,4 @@
 // but the two halves state ONE version: a module declares a single coreApi range
 // and is served one chunk, so a client that claimed 1.0.0 while the server
 // answered 1.1.0 would be two answers to one question.
-export const MODULE_API_VERSION = '1.2.0'
+export const MODULE_API_VERSION = '1.3.0'