feat(core): add the mcp kernel with agent tool and action-type registries

[mp-blurify]

Summary

Adds the MCP kernel to @openora/core: modules register agent read tools (ctx.mcp.tool) and proposable action types (ctx.actions.register) in their own plugin.ts, and consumers reach both
only through MCP_KERNEL. First registrations: tools player.summary, wallet.activity, kyc.status, ggr.summary; action types add_tag, add_note, hold_withdrawal,
send_to_manual_review, request_enhanced_kyc.

Why

An agent runtime and an MCP transport need to call module capabilities without importing modules, under the same IAM and audit rules as the Backoffice. A spike on real models showed what no
runtime enforces: a top-level oneOf made models send amounts as strings, tool output and thrown errors (including SQL text) reached the model verbatim, a restart executed an action twice, and
a model proposed a bonus to a player with harm signals.

So the kernel enforces it:

• it rejects unsafe input schemas at boot;
• it checks IAM per call through AdminGuard.assertUser;
• it returns only allow-listed output and maps exceptions to declared codes;
• it writes one audit record per call, with hashes rather than data;
• it requires a precondition hook before a proposal and replay-safe executors.

Also included:

• RunContext;
• PlatformConfig.agents: limits, retention, and a model allow-list of <gateway>/<vendor>/<model>, with the gateway list defaulting to openrouter;
• a trigger catalog derived from domain events;
• the agent, agent-proposal and agent-config IAM resources;
• a withdrawal hold (on_hold);
• the agent surface in the catalog and @openora/mcp (list-agent-tools);
• Container.registerSealed, which binds MCP_KERNEL so nothing can replace it after boot.

See ADR-0042.

Alternatives considered

• One registry for reads and writes: a write needs approval, an idempotent executor and a reversible flag; a read needs none.
• Enforcement in the runtime: every runtime tested forwarded output and errors verbatim, so each consumer would re-implement the rules.
• A rebindable kernel token: an overlay could bypass IAM and audit, so createApp binds it sealed after every plugin, and a later registration throws.
• Pseudonymisation in core: it needs a mapping store and belongs at the model boundary. Tools declare personal keys (redact.personal) instead.

Risks

• Breaking (types):
  • A hand-written ModuleRegistry needs actions, mcp.getTools and the two-argument mcp.tool.
  • A TypeScript PlatformConfig literal needs agents; config files parse unchanged.
  • The one-argument ctx.mcp.tool still registers, but the kernel does not serve it.
• Behaviour: admin approve and reject now accept an on_hold withdrawal, and an on_hold withdrawal blocks deleting its wallet asset. Only hold_withdrawal sets on_hold. Approving a held withdrawal clears the hold's reason; the hold's audit record keeps it.
• Registration: a tool output schema that lets undeclared keys through at any depth (a loose or catchall object, a record, an untyped field) fails boot, and checkPrecondition checks the caller's grant like an execution, so a hub calls it with an actor that holds the action type's permission.
• Migrations: wallet 0028 adds an index on wallet_transaction (wallet_id, status, created_at) with a plain CREATE INDEX, which blocks ledger writes while it builds, so apply it in a quiet window on a large ledger; player-note 0001 adds a nullable proposal_id under a partial unique index, which is instant.
• Roles: only Super Admin and the static admin role get the new IAM resources. Grant them to other roles before gating a screen on them.
• Replays: executors are replay-safe on the state they write, because core stores no proposals; only add_note keeps the proposal id, on its note under a partial unique index, so it adds one note per approved proposal. The hub must not re-execute a proposal it recorded as executed.
• Audit: every kernel call writes an audit row, so volume grows with agent traffic. Input hashes are deterministic, so a hash of a low-entropy input such as a player id is pseudonymous, not
  anonymous.
• Custom identity reader: an operator's own IDENTITY_READER without the new optional getUserIdByPlayerId gets a boot warning, and four registrations answer internal_error.

[zaxovaiko]

Not quite yet - the precondition IAM gap, the rebindable MCP_KERNEL and the shallow output allow-list. Minor:

• recordExecutionAudit returns audit_unavailable after the effect is already committed, so the caller sees a failure for an applied action.
• hold_withdrawal writes the proposed reason into reviewReason, so approving a held row keeps the hold text, and a reason of auto-approved counts toward the cap.
• The changeset says breaking types but bumps minor.
• No retention job for the audit row every kernel call writes. But that's for later.

[mp-blurify]

On the minor points:

• audit_unavailable after a committed execution is on purpose (ADR-0042, audit.md): an execution retries the write three times, then fails rather than return without its record. A replay answers already_applied and writes it, and the executor's own audit row commits with the effect either way. Writing the kernel's record in the executor's transaction would need a tx-aware executor contract, which is bigger than this PR.
• hold_withdrawal: approving a held withdrawal now clears the hold's reason (735431e); the hold's audit record keeps it. A held reason reading auto-approved still counts toward the daily cap on purpose (b93d5b2): the cap query stays as dev has it, and that case only fails closed.
• Changeset: core now bumps major (70b818a); @openora/mcp stays minor since it only adds tools. The summary also covers this round's fixes and the index migration's write lock.
• Retention: agreed, later. audit_log is append-only by trigger, so it needs an archive or partition design rather than a delete job.