Connection machine owns the provider state

[fernandomg]

User story / Problem statement

CantonConnectProvider mirrors dApp-SDK state into ~10 useState fields written from six places (#76's original complaint).

Two lifecycle models live side by side; one must win.

Expected outcome

• hooks read one source of truth: the machine's snapshot;
• connect() publishes the connection state and hands back an answer;
• the useState mirror is gone.

Acceptance criteria

• Hooks derive from the machine snapshot; the useState mirror is deleted;
• connect() publishes state and returns an answer;
• Race 3 pinned: unmount aborts the in-flight attempt end to end;
• Race 4 pinned: a late answer cannot overwrite fresh state;
• Race 5 pinned: an SDK swap leaves no stale listeners (teardown before the client swaps).
• The connect actor passes the wallet's answer through untouched; the machine guards declines itself (see feat: session states and wallet pushes #93).
• Restore/startup failures are surfaced to the consumer, not swallowed;
• useExecute / useSignMessage / useLedger guard on session.authenticated, not status === 'connected', so a locked wallet is rejected;
• party is read from an accounts machine invoked on session.authenticated entry; useParty derives from its snapshot, no useState mirror.

Technical notes

Blocked by #84.

The provider holds one actor: createActor(connectionMachine.provide({ actors })).

Real connect / restore / listener actors wrap the DappSDK facade.

This issue will also solve:

• canton-connect's provider leaks listeners on concurrent connects and hides startup failures #57's surface silent restore failures;
• A locked wallet passes the guards in useExecute, useSignMessage and useLedger #58's locked-wallet guard.

Regarding Party: a separate accounts machine (invoked by connectionMachine) will handle parties/party.