Create committor outbox intents directly from user transactions

Goal

Create committor outbox intents within the originating user transaction, making durable intent creation atomic with the transaction’s account changes.

Why

User transactions currently append intents to MagicContext, which the committor drains periodically. Its fixed 5 MiB capacity can be exhausted between drains, causing scheduling transactions to fail with AccountDataTooSmall. Updating the queue also rewrites the shared buffer.

The #1701 workstreams provide durable outbox lifecycle, recovery, and execution machinery. Write into that machinery directly instead of retaining MagicContext as an intermediate queue or replacing it with a volatile TLS queue.

Scope

Replace MagicContext staging and periodic acceptance with outbox creation through the authorized Magic Program/outbox builtin path. Failed transactions must leave no surviving intent, and execution must begin only after the originating transaction commits.

Reuse #1703’s outbox lifecycle, #1702’s durable progress and transaction reconciliation, and #1705’s processor ownership. Notifications may wake the processor, but outbox accounts remain the authoritative record of pending work.

Adapt instruction builders and account inputs so user transactions can identify and create their outboxes. The existing creation path requires validator authorization; introduce the appropriate user-transaction admission path without weakening ownership, signer, or account validation. Preserve intent ordering, retry identity, and AddActionCallback behavior.

Account for already-staged MagicContext intents and existing callers during rollout before retiring the old acceptance path. Do not introduce a second persistence or recovery mechanism.