Cover the shared-lock refusal and codec paths end-to-end by driving the lock from client-go

[eduralph]

tikv/client-rust PR 556 lands a refusal posture for shared locks plus wrapper-aware API-v2 keyspace codecs, and every one of those paths is currently proven by unit tests only. The reason is the cluster pin, not the design — see the companion issue #48.

Once the pin moves, the harness is in a position neither client's own CI is: it drives both clients against one server, so it can have the oracle create a shared lock and then observe what client-rust does with it. client-rust deliberately cannot acquire one (that refusal is the point of tikv/client-rust PR 556), but client-go can — kv.SetKeyLockedInShareMode sets flagKeyLockedInShareMode, which getLockTypeFromFlags turns into kvrpcpb.Op_SharedLock on prewrite (txnkv/transaction/2pc.go).

That makes the missing coverage reachable: a Go-driven setup step, then a Rust-driven observation step.

Scope:

• Scenario: client-go acquires a shared lock on a key; client-rust then runs scan_locks over it and resolve_locks against it.
• Assert the two behaviours tikv/client-rust PR 556 actually introduces:
  • Codec — the wrapper's own key comes back decoded (logical), its members decoded, and its unset primary_lock survives untouched. This is the pair of defects the split's review pass caught, and neither has an end-to-end test today.
  • Refusal — resolution returns the explicit error rather than resolving transaction 0 or silently dropping members.
• Declare the result in ledger.toml as a claim, so it goes loudly red if either side changes.
• Confirm against the real wire what was so far only read out of TiKV's source: that a wrapper sets lock_type, key and shared_lock_infos while leaving lock_version/primary_lock at their defaults (SharedLocks::into_lock_info). The codec in tikv/client-rust PR 556 is written to be correct either way, but this would settle it by observation instead of by reading.

Distinct from #42, which is full shared-lock support in client-rust (flattening wrappers, teaching the resolver SharedPessimisticLock, cleanup-filter awareness). This issue only covers the refusal-and-codec posture that tikv/client-rust PR 556 ships; #42's own differential bullet lands later, on top of this scenario.

Blocked on #48 (the cluster pin bump) — no v8.5.5 server can produce the input.

Roadmap §8 (verification) / Phase 0 — closes the coverage gap declared in tikv/client-rust PR 556.

[eduralph]

Status 2026-09-11. tikv/client-rust#556 merged 2026-08-05, so this scenario would now cover shipped upstream code rather than a PR. Still blocked on #48 — nothing else is in the way.