conformance: with_opaque is not a valid wire value, and it blocks adapters from calling the real SDK challenge-id functions (fix ready)

[EfeDurmaz16]

PR creation is currently restricted to collaborators, so filing this as an issue. The fix is complete and tested on a branch ready to pull: EfeDurmaz16:fix/challenge-id-real-sdk (2 commits, +41/-55). Happy to open it as a PR if you enable that or pull it directly.

Two coupled fixes so a conformance run certifies a shipping SDK instead of harness glue.

1. with_opaque used opaque: "trace-123", which is not decodable base64url (invalid length). Per the core spec, wire opaque is base64url of a JCS flat string map, and HMAC slot 6 binds that wire value, so no compliant server can emit "trace-123". Replaced with eyJ0cmFjZSI6IjEyMyJ9 and the expected id regenerated:

HMAC-SHA256("test-vector-secret-minimum-32-byte-secret",
  "api.example.com|tempo|charge|eyJhbW91bnQiOiIxMDAwMDAwIn0|||eyJ0cmFjZSI6IjEyMyJ9")
= base64url: 5kAjSWiLlrX5yinRSJ9gZPiGWd_AC3WG_jAOcBnH6iY

2. With the fixture valid, the Go adapter now calls the real mpp.GenerateChallengeID (mpp-go v0.2.0, already a direct dependency) and drops its local reimplementation, as its own TODO comment suggested. The minimum-secret-length guard stays adapter-side because the library does not enforce one and error_weak_secret_key expects generation_error.

Verified locally with vector_runner: go 119/119, typescript 125/125, rust 120/120, python 126/126. ruby/java put opaque into the same pipe-join as a raw string, so the regenerated id is adapter-independent; CI will confirm. opaque_route_scope_binding is byte-for-byte unchanged.

Follow-up offer: the same swap for the python and rust adapters.

[ygd58]

Independently verified both claims computationally:

• "trace-123" (9 chars) has an impossible base64url length — unpadded base64 length can never be ≡ 1 (mod 4), and 9 mod 4 == 1. It genuinely can't have been a valid wire opaque value.
• Recomputed the HMAC by hand: HMAC-SHA256(secret, "api.example.com|tempo|charge|eyJhbW91bnQiOiIxMDAwMDAwIn0|||eyJ0cmFjZSI6IjEyMyJ9") → 5kAjSWiLlrX5yinRSJ9gZPiGWd_AC3WG_jAOcBnH6iY, matches exactly.

Also checked the actual diff on the branch — the old code's generateConformanceChallengeID had a comment explaining it added special-case "raw-string opaque" handling specifically because the conformance vector didn't match the library's real behavior, rather than the vector being wrong. Removing that workaround and calling the real mpp.GenerateChallengeID (per the branch diff) is the right fix — it makes the Go adapter test the actual shipping library instead of a local reimplementation that existed only to accommodate a malformed fixture.

This looks correct and ready to merge whenever PR access allows.