feat(connect): expose the party type on useParty

[fernandomg]

Summary

Closes #5

A Canton party is local or external: a local party's keys live on the participant hosting it, an external party signs for itself. A dApp cares because the reference gateway refuses signMessage for a local party, and today an app learns that only when the call fails.

CIP-0103 does not say which kind an account is. This PR passes namespace and signingProviderId through on Party as the wallet reports them and adds usePartyType, which answers when asked: readPartyType() reads the participant id through ledgerApi and compares its namespace with the party's. Nothing runs at connect; a failed read rejects and the consumer decides.

Changes

• Party carries namespace and signingProviderId as the wallet reports them
• usePartyType() returns readPartyType, resolving 'local' or 'external', and isReady
• PartyType is exported
• Architecture doc gains the party type seam; connect CLAUDE.md states what the machine owns and what a hook does

Deviations

• The type comes from a hook, not a Party field: a field would put a ledger read at connect for a fact only some consumers need
• No held result, pending or error state: readPartyType is a plain async read, the shape a query layer (TanStack Query) wraps later
• The dApp consumes nothing yet: gating sign-in with wallet on readPartyType() and showing the kind in AccountMenu is its own issue
• The other three criteria were already true or are wallet-side: one SDK call covers prepare, sign and execute; actAs, readAs and disclosedContracts pass through verbatim; there are no connectors to keep consistent

Acceptance criteria

• Party/useParty expose the party type (local vs external), through usePartyType
• useExecute supports the full external prepare→sign→execute cycle
• disclosedContracts and actAs/readAs scoping are threaded through execute calls where relevant
• Behavior is consistent across extension, remote, and WalletConnect connectors

Test plan

Automated tests

1. pnpm -C canton-connect test: local, external, refusal, malformed answer, no party

Manual verification

1. LocalNet up, mint a token with pnpm run mint-token
2. GET http://localhost:2975/v2/parties/participant-id with it: 200 and { "participantId": "participant::<namespace>" }
3. GET http://localhost:2975/v2/parties: Carpincho's parties report isLocal: true under their own namespace, the bootstrap operators under the participant's; the namespace is the signal, isLocal is not

The dApp does not consume the hook yet.

Breaking changes

Party gains two required fields, namespace and signingProviderId. A FakeSessionProvider given a hand-built party needs both.

Checklist

• Self-reviewed my own diff
• Tests added or updated
• Docs updated (if applicable)
• No unrelated changes bundled in

Screenshots

None.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
demo.canton-dappbooster	Ready	Preview	Sep 7, 2026 3:08pm UTC
docs.canton-dappbooster	Ready	Preview	Sep 7, 2026 3:08pm UTC

[gabitoesmiapodo]

CC reported a few things not worth your time (but worth mine, it seems...), mostly very unlikely edge cases... nonsense crap.

So: LGTM.