refactor(app): split CapTableDashboard write/refresh orchestrator

[ThatAlexPalmer]

app/src/components/cap-table/CapTableDashboard.tsx is ~977 lines. Views (HoldingsView, IssueStockView, …) are already extracted; the leftover problem is that one component still owns every company-workspace side effect.

Today it holds:

• four useDirect* hooks + four handle* write functions (class, shareholder, issuance, transfer)
• optimistic in-flight rows + 90s TTL + pending flags
• issuer deployed_to self-heal fetch
• soft reconcile on open + Refresh
• activity log (localStorage) + historical TX load
• success/error modal + wallet/contract readiness gates
• view routing via ?view=

That is not a bug. It is hard to review, easy to regress (ghost classes, first-issuance dropdown, optimistic dedupe), and it mixes UI chrome with write-path policy that WARP.md already documents in prose.

What’s wrong

• Write handlers duplicate the same sequence: require wallet → submit → wait receipt → /register-onchain (except transfer) → optimistic row → activity.
• Effects for heal/reconcile/history are inline and depend on manager in ways that are easy to stale-close over.
• Nothing in this file is unit-tested; nav/ownership tests sit next to it but do not cover the handlers.

Suggested split (keep behavior)

Extract hooks, do not invent a new write protocol:

• useIssuerHeal / useIssuerReconcile
• useCapTableWrites (the four handlers + optimistic state)
• leave view switching + layout in the dashboard

Do not delete /register-onchain, optimistic TTL, or transfer-via-poller-only.

[ThatAlexPalmer]

CapTableDashboard.tsx is about 400 lines, not ~977. The 90 second optimistic TTL is gone. Session rows live in the dashboard until it unmounts.

The four write hooks stay. Issuance share-cap checks and transfer balance checks are not the same sequence as creating a stock class or shareholder.

Class and shareholder registration now waits for the wallet receipt and patches the optimistic row by id. If /register-onchain fails, the modal offers Save record, and a stock class is not marked ready to issue. The poller only updates an existing class or person, so a swallowed register used to drop the record after leaving the page. A second submit is ignored while that write is waiting for a receipt.

Closing this.