feat(events): open the event contract to modules (Phase 7)

MODULE_API 1.10.0. Four names forwarded on the module-facing `api` --
registerEventActions, registerEventBudgets, registerEventLeases and
registerEventOptionSources -- one new route, and one rule made real: a
`cost()` naming a dimension no module declared is refused.

Only one of the four is new machinery. The action registry has staged
core's three actions on every boot since Phase 1; what it never had was a
way in, because loader.js builds its own `api` facade and had no method
that delegated to it. So the registry a module now reaches is one that has
been exercised on every boot for six phases.

Four decisions, settled 2026-09-03, all as recommended:

- Option sources are their own registration, modelled on registerAudiences,
  because a catalog has more than one consumer.
- An undeclared dimension is refused -- at save, at the dry run and at
  dispatch -- with its own code, because the fix is a module's declaration
  and not a deployment's cap.
- A lease is declared here and acquired by nothing; the ledger is Phase 8.
- Core registers core.options.legs, so an announce leg is a dropdown rather
  than the free-text box whose typo Phase 6's walk caught mid-run.

Proved with a throwaway module through the real loader, not with module-uo:
eventModuleContract.test.js writes a module to a real directory and lets the
loader scan it, covering all five envelope failure shapes, verify: true, the
four id spaces and dormancy on uninstall.

The live walk found the one defect nothing else could: the option-source
loader wrote its "already asked?" guard inside a setState updater and read
it on the next line, so the request was never made and the field sat on
"Reading the list..." for ever. It is a useRef now.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T6t8mrAWhZU5vnyYgZTMtL

client/src/modules/version.js

@@ -11,6 +11,15 @@
 // 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.10.0 — the event contract opens to modules (EVENTS.md §F, EVENTS_PLAN.md
+// Phase 7): a module may register event actions, budget dimensions, leases and
+// param option sources. All four are server-side registrations and nothing on
+// `window.__rg` changed — but what they produce is met on this half, in the step
+// editor: an option source is what turns a param from a text box into a dropdown
+// of real values, and a budget's label and unit are what the switchboard's cap
+// box says beside its number. This file bumps for the reason at the top: the two
+// halves state ONE version, and a module declares one `coreApi` range against
+// both.
 // 1.9.0 - a module may ship its own message bodies and rules:
 // `api.registerEngagementSeeds({ templates, ruleGroups })` (ENGAGEMENT.md Phase
 // 11b, decision 7). Nothing on this half changed - a seed is server-side data
@@ -65,4 +74,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.9.0'
+export const MODULE_API_VERSION = '1.10.0'