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/featureGate.js

@@ -3,22 +3,22 @@
 // Phase 2, PR 8 of docs/website/MODULE_SYSTEM.md §2.7 (§1.5 states the problem);
 // the contract is docs/website/MODULE_API.md §3.3.
 //
-// Ten of the sixteen rows in the public header carry a `feature`, and every one
-// of them is a shard surface an admin can disable or gate to a higher audience.
-// The provider that answers those questions — `useShardFeatures` — moves out
-// with the module, so core cannot keep calling it directly and still be a core.
-// It keeps a generic seam instead, and the module fills it.
+// Nine of the sixteen rows in the public header used to carry a `feature`, and
+// every one of them was a shard surface an admin can disable or gate to a higher
+// audience. The provider that answered those questions moved out with the module
+// in Phase 3 slice 3, and core cannot call it directly and still be a core. It
+// keeps this generic seam instead, and the module fills it.
 //
 // **The namespace comes from the registration, not from the string.** A row's
 // `feature` is resolved by the provider its OWN module registered, so a module
 // author writes `feature: 'status'` exactly as it reads today: nothing parses a
 // prefix, and a typo'd namespace is not a thing that can exist. Core's own rows
-// carry no `moduleId` and resolve against the owner id `core`, which is what
-// core registers `useShardFeatures` under until Phase 3 moves those rows into
-// the module and they arrive stamped `uo` instead.
+// carry no `moduleId` and resolve against the owner id `core` — which nothing
+// registers now that the shard rows are gone, and that is the correct resting
+// state rather than a gap: no core nav row carries a `feature`.
 //
-// Everything here fails OPEN, and that is deliberate and unchanged from
-// useShardFeatures' own posture: this is presentation, the gate is server-side
+// Everything here fails OPEN, and that is deliberate: this is presentation, the
+// gate is server-side
 // (a disabled feature 404s and an out-of-rung one 403s whether or not a link was
 // rendered), so an unknown answer shows the link rather than blanking the nav.
 // The one thing a UI mistake must never do here is hide a page from someone