[geoffturk]

Fixes #377.

The problem

A trigger-link sign-in (auth/oob/*) is the first option on a VTC operator console's login page, and it was the only wallet sign-in that seeded no origin → relying-party pin (origin-pin.ts, M5). The console's Set up signing with your wallet calls signTrustTask, which is bound to that pin and deliberately never seeds one. So a wallet administrator who signed in the recommended way was refused with <origin> has no relying party pinned … and could never enrol a console signing key. Only the two page-bridge SIOP sign-ins, now labelled deprecated on that login page, left a pin.

The change

• Pin on approval (background.ts). When a trigger-link flow ends with an approved grant, handleSignInStep pins the click's browser-attested origin to the community DID the link names, through the existing pinOrigin. That is the pairing the flow already verified: it refused unless that origin was the portal the community's own DID document names (VTI-LNK-105). The link is parsed with now: 0, as handleTriggerLinkNumber does, so a link that lapsed while the person was approving still names its community.
• The changed-pairing warning is kept. M5's rule is that a page asking for a different relying party than it was pinned to gets a loud prompt, as the page-bridge logins give it. On prepare the background now forwards what the origin is currently pinned to (pinnedDid). The flow (sign-in-flows.ts) adds changedFromDid to the confirm screen when the link's community differs. The window (sign-in-view.tsx) shows a danger note naming the previous community and no longer skips the confirm screen for a single identity in that case, so the warning is seen before anything is sent.
• Types (bridge-protocol.ts): pinnedDid? on the offscreen prepare request, changedFromDid? on the confirm result. Both optional and additive.
• Tests: a flow test that the confirm screen carries changedFromDid only when the pinned DID differs from the link's community, and a render test that the warning is shown, no claim goes out on its own, and Continue is offered.

page-task-policy.ts is unchanged: no pin still means no signature.

Judgment calls for the reviewer

1. Where the pin is seeded. The background pins from the stored flow record (the attested click origin) and the link's from, rather than the flow returning the pairing it verified in its done result. This keeps SignInStepResult's done shape stable and leaves four deepEqual assertions on it untouched. The two are equal by construction today (the flow's vtcDid is link.from.value, and it refuses unless origin matches the portal), but if you would rather the flow report what it verified, done could carry { vtcDid, portalOrigin } on an approve and the background would pin from that instead. Happy to switch.
2. Overwriting an existing pin. An approved sign-in overwrites a pin to a different community, as the page-bridge logins do once the person approves past the loud prompt. The alternative of refusing to overwrite would leave the person with no way back short of clearing extension storage, which has no UI. The warning on the confirm screen is what makes the overwrite an informed one; it is also why a single identity no longer skips that screen when the pairing changed.

Verification

Built with the Docker workflow from the working tree: lint, tsc, npm test (1317 + 6 + 9 passing, the two new tests among them) and CI's post-build assertions all pass. The unpacked build loads with the pinned extension ID.

Exercised end to end against a live VTC (test-vtc.openvtc.net, operator console, a did:webvh persona with community-admin): after Sign in with your wallet the origin is pinned and Set up signing with your wallet succeeds, where the same steps on the previous build were refused with has no relying party pinned.