fix(did): stop advertising a TSP service the holder cannot publish

[stormer78]

#135 doesn't work, for two independent reasons

It added a TSPTransport entry to the holder's did:peer:2, so an executor would have a capability signal to negotiate a push against.

1. Nothing calls the function it was added to. Onboarding adopts a VTA-minted holder via installVtaMintedHolder (provision-integration, M2C). ensureHolder's self-minting path is the earlier design and is currently unreached — grep finds no callers.
2. The adopted holder is a did:key, and that method has no service endpoints at all. Its document is derived from the key material alone.

The second reason is the one that matters, because it rules out the approach, not just this call site. Publishing capabilities in the DID document was chosen over announcing them at enrolment on the strength of symmetry — both sides resolving and matching published services — and that symmetry simply isn't available to a did:key holder. No amount of moving the code fixes it.

Reverted, with both reasons recorded at the site so the next attempt doesn't rediscover them.

What stays

createDidPeer2's multi-service support. It is the correct shape for a peer DID, it is exercised by tests, and it is what the self-minting path would need if a peer-DID holder ever returns.

Its doc now says plainly that nothing publishes a second service today, so a reader cannot infer from its existence that holder capabilities are discoverable. That inference is exactly what I made.

Consequence for the negotiated push

The signal has to live somewhere a did:key can carry it — announced at enrolment and held against the ACL/device record, which the VTA reads at push time. That is a contract field to agree with the Rust side rather than a DID-document read, so it wants deciding before the VTA-side push is built rather than during.

467 core tests pass; lint and build clean.

How this got merged

Worth recording, since the review didn't catch it either. I verified that createDidPeer2 mints a did:peer:2 and that both resolvers decode a second service correctly — all true, and all irrelevant, because I never checked that anything calls it. The evidence was in the first screenshot of the thread: the wallet address read did:key:z6Mku54v….