Track Ruby, PHP, and Lua process adapter path

[EfeDurmaz16]

Context

The current interop adapter track is intentionally split into small pieces. Issue #57 tracks Python and Go process adapter parity, and the Go client/server adapter PRs already make that path concrete.

Once that core matrix is stable, it would be useful to keep a separate lightweight track for additional language adapters that matter in merchant/backend and agent plugin environments: Ruby, PHP, and Lua. This should stay separate from #57 so Python/Go work remains focused.

Proposed scope

Keep this incremental:

1. Reuse the existing process-harness contract.
2. Add one language at a time.
3. Keep client and server adapters as separate PRs where possible.
4. Start each language as opt-in/local before adding it to the default CI matrix.
5. Promote an adapter to CI only after the local path is stable and not noisy for unrelated PRs.

Adapter expectations

Each adapter should preserve the same harness shape:

• 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/config provides RPC URL, network, mint, price, pay-to address, client key, fee payer key, and MPP secret
• stderr remains diagnostics-only so stdout stays machine-parseable

Why this matters

Ruby, PHP, and Lua show up in real server and plugin surfaces where paid resources may be exposed. Adding them to the same cross-language matrix would help catch implementation drift in:

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

A small first step already exists on the Ruby side in stripe/mpp-rb#13, which documents a Ruby adapter contract for cross-language conformance. Follow-up implementation PRs can stay small and language-specific if maintainers want to continue in this direction.