Track Python and Go process adapters in the interop matrix

[EfeDurmaz16]

Context

The current interop harness is already structured around process adapters and currently exercises the TypeScript/Rust matrix by default. PR #52 starts adding a Go client adapter, which is a good first step toward exposing cross-language gaps.

It would be useful to track the remaining adapter parity work explicitly so each language can be added in small, reviewable PRs without turning the harness into one large change.

Proposed scope

Suggested sequence:

1. Land the current Go client adapter work.
2. Add a Go server process adapter.
3. Add a Python client process adapter.
4. Add a Python server process adapter.
5. Enable each new adapter in CI only after its local harness path is stable.
6. Keep the default stable matrix clear in the interop README and CI env.

Adapter contract

Each adapter should follow the existing process-harness contract:

• server writes one ready JSON line with its bound port
• client writes one result JSON line with status, response body, response headers, and settlement evidence
• shared env vars provide RPC URL, network, mint, price, pay-to address, client key, fee payer key, and MPP secret
• stderr remains diagnostic-only so stdout stays machine-parseable

Why this matters

The useful signal is not just whether each SDK passes its own tests. The interop matrix should catch drift between implementations in:

• WWW-Authenticate challenge parsing
• credential construction
• intent and method selection
• SPL transfer amount/decimal handling
• receipt and settlement header shape
• server-side verification assumptions

This issue is intentionally limited to adapter parity and CI sequencing. It does not require adding new protocol features.

[EfeDurmaz16]

Small status update on the adapter track:

• feat(interop): add go process client adapter #52 adds the Go process client adapter.
• feat(interop): add go process server adapter #58 adds the Go process server adapter.
• Both are disabled-by-default adapter additions and currently have green CI.

That gives the harness a concrete Go client/server shape without widening the default matrix yet. A next small slice could be tightening the Python adapter/client parity now that the Go process boundary is represented on both sides.