docs(ttx): versioning exploration for interactive protocols

[SuyashAlphaC]

This PR adds the design exploration document requested by @adecaro on #1620 and tracked under #1654. It is documentation only — no code or behavior changes.

The doc lives at docs/services/ttx-versioning.md and covers:

• A surface map of every interactive view in token/services/ttx/ that exchanges typed messages over FSC sessions
• Evaluation of four versioning approaches (embedded version field, envelope wrapper, negotiation handshake, alignment with Aggregated Protobuf Best Practices Analysis & Improvement Plan #1622)
• A recommended minimal v1: a JSON envelope at the session helper layer, scoped to the four JSON-typed flows
• Mixed-version policy options (strict / tolerant fallback / capability handshake) with a recommended starting point
• Coordination strategy with the proto-direction in Aggregated Protobuf Best Practices Analysis & Improvement Plan #1622 — placed at the same architectural layer so it can be replaced cleanly later
• A migration sketch and explicit open questions for maintainer review

The proposal is non-implementation by design — it asks for maintainer alignment before any code is written.

Test plan

• Markdown renders correctly
• All cross-references (docs(ttx): document recipient identity message flows (#1606) #1607, TTX recipient responder: bind before send; simplify identity.Provider isMeCache #1620, Aggregated Protobuf Best Practices Analysis & Improvement Plan #1622, feat(ttx): Milestone 3 — Recipient Wire Hardening (slimmer responses + nonce/signature) #1652, exploration(ttx): Versioning for Interactive Recipient Protocols #1654) point to real issues
• No code or test changes — N/A for build/test impact

Refs: #1654

[adecaro]

Hi @SuyashAlphaC , great effort, thanks 🙏

In the meantime, please, create an Issue with your first analysis in the description. I'll prepare an answer to it so that we can proceed with the implementation plan. What do you think?

[SuyashAlphaC]

Hey @adecaro . As per your note — moving the first analysis into the issue body at #1654 for discussion before any code lands. Closing this PR; will open a fresh implementation PR once the design questions there are answered.

Thanks 🙏