feat(e2e): standin Suite 5+6 — Rust provider-stack alongside Deno

[AquiGorka]

Summary

Adds end-to-end coverage for the Rust provider-stack standin as a first-class service in local-dev. The standin runs on the same infra cycle as the Deno provider-platform — separate port, separate DB, separate OTEL service name — so a single ./up.sh brings both up and a single ./testnet/run-local.sh all exercises both end to end.

What changed

Infra — the standin becomes a first-class service

• lib/master-seed.ts: new ROLES.STANDIN_PP role. Deterministic per master seed; distinct from ROLES.PP so the standin's chain identity doesn't collide with the Deno PP.
• setup-keys.sh: emits STANDIN_PP_PK / STANDIN_PP_SK to .local-dev-keys.
• infra-up.sh: new section 5b spawns the Rust standin alongside the Deno provider — $BASE_DIR/provider-stack/target/release/provider-stack, port 3011, OTEL_SERVICE_NAME=provider-platform-standin, dedicated provider_stack_db auto-created on the existing postgres. Best-effort: skipped with a warning if the binary or keys aren't there yet.
• infra-up.sh: pinned stellar container start local to --image-tag-override v639-b1103.1-latest — the rolling :testing tag has been rejecting all WASM uploads with HostError(Context, InternalError) since 2026-06-15. PR fix(ci): pin stellar/quickstart to v639-b1103.1-latest (node regression) #120 pinned the docker-compose paths; this pins the CLI path used by up.sh.
• down.sh: also stops .standin.pid so a re-up doesn't leak the previous standin onto port 3011.

Test — new Suites 5 + 6

• lifecycle/standin-verify.ts (new): mirror of testnet-verify.ts pointed at :3011 with PP derived from ROLES.STANDIN_PP. Single-PP: no /dashboard/pp/register step (the standin's PP is env-pinned at boot). The rest of the flow (deploy → council → join → approve → on-chain add_provider → watcher promote ACTIVE → deposit/send/withdraw) is byte-identical.
• lifecycle/standin-verify-otel-local.ts (new): wraps the OTEL verifier with providerServiceOverride: "provider-platform-standin" so it queries the standin's traces specifically.
• lib/verify-otel-local.ts: new optional providerServiceOverride option. Used only by the standin wrapper; Deno path unchanged.
• lib/client/{config,bundle,register-entity}.ts: optional urlShape: "multi-pp" | "single-pp" (default multi-pp). When single-pp, bundle URLs become /api/v1/provider/entity/bundles and the entity-register endpoint becomes /api/v1/provider/entities — matching the standin's single-PP route shape. Defaulting to multi-pp keeps every existing Deno call site behaviour-identical.
• testnet/events-capture/{harness,subscribe}.ts: per-script config (ppRole, perSuiteSecret, urlShape) lets the standin script use ROLES.STANDIN_PP, skip the per-suite KDF (the standin's PP is fixed at boot, not per-suite-derived), and use the single-PP WS URL + /dashboard/pp (singular) sanity check.
• testnet/run-local.sh: new Suite 5 (lifecycle → standin via events-capture) + Suite 6 (OTEL verify standin), standin alias, extends all to run all six.

Validation

./testnet/run-local.sh standin — 15 consecutive runs, every assertion green:

metric	result
Suite 5 lifecycle	PASS every run
per-PP WS events	12/12 every run
network WS events	5/5 every run
Suite 6 OTEL spans	23 passed, 0 failed every run

Same env-pinned PP (GBKV…CV7FR) on every run, no flakes.

Test plan

• ./down.sh && ./up.sh && ./setup-c.sh
• ./testnet/run-local.sh standin — Suite 5+6 alone, both green
• ./testnet/run-local.sh all — Deno (1-4) + standin (5-6) all six green
• Re-run standin several times against the same stack — verify stable