feat: CLL auth/jsonrpc passthrough + WS call accounting on rewritten feat/websocket-support

[snowkide]

Summary

Rebased 2026-10-07 onto fix/fallback-tier-subscriptions (#31), the version now running in production. Previously stacked on fix/fallback-tip-leader (#29, closed). Old tip 6dfd658e -> new tip 11108fd2. Both commits applied without conflicts on top of #31's three commits (hedge all-missing leg, fallback heads holdback, filter subscriptions on head tiers). Once #31 merges into feat/websocket-support, retarget this PR there.

Original context: feat/websocket-support was rewritten on 2026-09-28: rebased onto upstream 989cfe60 and squashed to 11 commits (old tip kept as backup/feat-websocket-support-2026-09-28). #24 still sits on the old history. This PR re-applies #24's net change onto the new history and adds WS observability. #24 is not modified.

Commit 1: port of #24 (#20 + #21 + #23)

• forwardedClientId auth strategy. The secret is also accepted as path /<secret>, ?apikey= and header (NewPayloadFromHttp now takes the URL path).
• jsonrpc passthrough architecture. It now sits next to upstream's new svm architecture in config, defaults, validation, network IDs and the registry, and it's registered as a no-op ArchitectureHandler because the new architecture registry requires one. Its error extractor claims nothing, so errors still go through the EVM extractor, the same as in prod today.
• "error": null is treated as success, and empty params are omitted (BTC-family / Stellar).

Commit 2: count every WSS call and add per-client metrics

Today network_request_received_total{transport="ws"}, which CLL's rpc_ws_event_count_total is built from, only counts WS requests that reach Project.Forward or eth_(un)subscribe. WS requests rejected earlier are invisible: invalid, method not allowed, auth failure, project or auth rate limit, network unavailable, and batch parse errors.

Metric	Labels	Purpose
network_request_received_total	+ transport	ported from #20
ws_requests_total (new)	category, user, agent_name, outcome	every WS JSON-RPC request counted once, including rejected ones. category="n/a" until authenticated (protects cardinality)
ws_subscription_events_total	user, agent_name	ported; notifications delivered
websocket_subscription_notifications_dropped_total	+ user, agent_name	base's drop counter, now per key
ws_subscriptions_active (new)	kind, user	gauge
ws_connections_active / ws_connections_closed_total (new)	close_code, initiator	connection churn
client_request_duration_seconds (new)	network, user, transport, outcome	per-key latency. chainlink-erpc drops user from all histograms, so network_request_duration_seconds can't be broken down by key

How the two histories diverged (for review)

• Old history (feat: CLL non-EVM jsonrpc passthrough (combine #20+#21+#23) #24's base) ended with a merge of upstream main plus fix(evm): guard nil upstream on cached eth_getBlockByNumber stale metrics #26 (stale-block nil-upstream guard). The new history is a linear rebase. A symbol check suggests the LinkPool fixes (fix(failsafe): release half-open permit on ignored outcome (breaker wedge / probe-selection wedge root cause) #3 breaker permit, fix(initializer): keep auto-retry alive for transient tasks despite fatal or hung siblings #5 initializer, fix(ws): pin near-tip getBlock to EvmLeaderUpstream #14 near-tip pin, fallback escape, self-heal) are present in the rewrite, mostly reworked (for example TipHW became the delivered-head floor). Jonny should confirm that fix(evm): guard nil upstream on cached eth_getBlockByNumber stale metrics #26 and fix(ws): skip tier:fallback escape on TipHW tip re-fetch #13/fix(ws): skip gzip ResponseWriter wrap on WebSocket upgrades #17 are still needed.
• The rewrite dropped .github/workflows/ghcr-publish.yml (303b094). It still exists on main, which is the copy workflow_dispatch runs, and it builds any ref, so this branch can still be built.

Test plan (on the rebased tree, 2026-10-07)

• go build ./.... go vet on changed packages is clean apart from an existing upstream warning in erpc/query_executor_test.go:341 (from feat: unified selection policy and scoring mechanism erpc/erpc#888)
• go test ./auth ./common ./util ./indexer/... ./telemetry ./clients ./upstream ./architecture/... pass
• go test ./erpc -run 'TestWebSocket_|TestAdapter_PerClientMetrics|Subscription' -race pass
• Label count matches the definition at every call site of each changed or new metric (network_request_received_total +transport, dropped-notifications +user/agent_name, the new ws_* metrics, client_request_duration_seconds). A mismatch would only show up as a panic at runtime
• Full go test ./erpc (running; result will be posted in a comment)
• Canary on chainlink-erpc with a non-EVM network (BTC-family / Stellar) over HTTPS and WSS

🤖 Generated with Claude Code

[snowkide]

Full go test ./erpc/ -count=1 on the PR tree: ok github.com/erpc/erpc/erpc 1023.610s (exit 0). TestNetwork_Forward/ForwardLlamaRPCEndpointRateLimitResponseSingle, which #29 lists as failing on 05126d0, also passed in this run.

[snowkide]

Full go test ./erpc/ -count=1 after the rebase onto fix/fallback-tier-subscriptions (tip 11108fd2):

• Rebased tree: everything passes except TestWebSocket_ShutdownClosesPromptlyAfterInflightRequests (999s, exit 1).
• Unmodified fix/fallback-tier-subscriptions base, same run: ok github.com/erpc/erpc/erpc 1012.360s.

That test fails on the base too. Running only that test with -count=20: 3/20 fail on this PR, 5/20 fail on the base. The test file is identical on both branches. In each failure, the in-flight eth_getBalance got "result":"0x1" back instead of the delayed 0xabc123 gock mock (ws_server_hardening_test.go:238). So the flaky test is in #31's base and isn't caused by this PR. It looks like another mock answers the request before the delayed eth_getBalance filter mock does.

Still to do: a canary on chainlink-erpc with a non-EVM network (BTC-family / Stellar) over HTTPS and WSS.