fix(test): provision chains with working seid config (smoke-proven)

[bdchatham]

Follow-up to #430 — make TestBenchmark actually bring up a chain

In-cluster smoke of TestBenchmark on harbor (run via an in-cluster pod with a harness SA) caught two real gaps the SDK's generic provisioning left vs the old scenario templates:

1. Validators CrashLooped — seid exits with invalid state-commit.sc-write-mode "cosmos_only". Every scenario template set storage.state_commit/state_store.write_mode=memiavl_only; the SDK's CreateNetwork omitted it. provision now applies that storage baseline to the network + every node.
2. Load followers need the EVM tuning the rpc template carried (evm.worker_pool_size/worker_queue_size/max_tx_pool_txs); TestBenchmark passes it via spec.rpcConfig, merged over the baseline.

Proof (live, harbor)

network ... ready
rpc-0: running -> caught up -> EVM serving
rpc-1: running -> caught up -> EVM serving
--- PASS: TestBenchmark (353.16s)   # provision -> 2m seiload -> all followers caught-up post-load -> clean teardown

Resources fully reaped after (DeletionPolicy cascade + t.Cleanup).

Run-model RBAC note (for the cutover deliverable)

The SDK provisions via server-side apply, so the harness ServiceAccount Role needs patch/update on seinetworks/seinodes, not just create. Folds into the harness-Role manifest.

Verification

go build ./... clean · golangci-lint 0 issues · go test -c -tags integration compiles · passes in-cluster end-to-end.

🤖 Generated with Claude Code

[cursor]

PR Summary

Low Risk
Changes are confined to integration test provisioning and config wiring; no production controller or runtime behavior is modified.

Overview
Integration provisioning now passes per-suite seid config into the SDK so nightly chains match the old scenario templates instead of relying on controller defaults.

The harness adds memiavl_only storage write modes via spec.storageConfig, applied on CreateNetwork and merged onto RPC nodes. TestBenchmark sets that baseline plus EVM worker pool / queue / tx-pool limits on followers through spec.rpcConfig, aligned with the load scenario’s RPC overrides.

Suites that intentionally test default storage (e.g. major upgrade) can omit storageConfig; load/release suites opt in explicitly.

^{Reviewed by Cursor Bugbot for commit cf3554a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[bdchatham]

/xreview — 2 lenses (idiom · k8s-dissenter), RESOLVED

k8s [correctness]: baseStorageConfig was globalized in provision, but memiavl_only is not universal — major-upgrade's validator template deliberately omits write_mode (the storage/migration path is what that suite tests). Globalizing it would silently distort TestChainUpgrade once wired (latent today; only TestBenchmark is wired). Fixed: storage config is now per-suite (spec.storageConfig) — load/release set memiavlStorageConfig, upgrade leaves it nil → controller default. Byte-identical for TestBenchmark (smoke still valid).

k8s confirmed correct: config-key passthrough is verbatim (Config → CRD configOverrides, no drift); the SSA/RBAC note (Role needs patch/update — SDK uses server-side apply) is right and is a platform manifest deliverable; mergeConfig correct. The dropped template keys it flagged are release/upgrade-template, not load — load is faithful.

idiom: reads native; applied the two style nits (trim mergeConfig comment; maps.Clone for the network config copy). Shared-global concern vetted clear.

No one-way doors. Smoke-proven end-to-end on harbor.