feat(truapi-provider): cap the light client's live connections

[decrypto21]

Closes the last open decision on #463: the cap belongs in the provider.

The embedded light client holds at most 32 connections at once. A connect past that is refused with
ProviderError::TooManyConnections, and closing one hands its slot back.

Why the provider. Every resource a connection costs is allocated here and is invisible to whoever holds it: an
add_chain with its own request queue and response stream, a MAX_UNDELIVERED_FRAMES channel, and on the FFI path a
pump thread's stack. The crate also ships standalone, into processes with no TrUAPI host in them. And a host-side cap
could not bind: ChainRuntime::connection_for single-flights the provider connect per genesis hash, and the catalog
is eight chains, so a host sits at eight against a ceiling of 32.

Not covered. ws/RpcNode connections never reach LightState and stay uncapped; only the WASM build compiles
that backend. Each README states that boundary.

Verification. fmt, clippy --all-features and 91 tests pass, under every feature set CI builds including
wasm32-unknown-unknown. Each test is pinned against the mutation it exists to catch, including the
AddedChain::refcount sum that the counter's field doc argues against.

clippy --no-default-features --features uniffi already fails on main (provider.rs:221, a new nightly lint),
independently of this branch.

[github-actions]

CI Status: 18 required jobs green, 15 passed and 3 skipped by path filter.

All job results

job	result
android-bindings	success
changes	success
changeset-guard	success
cli-package	skipped
codegen	success
e2e	skipped
explorer	success
ios-bindings	success
ios-swift	success
licenses	success
playground	success
release-guard	success
rust	success
ts-client	success
ts-debugger	success
ts-host	success
wasm-provider	success
workflow-lint	skipped

_{Commit c0050cee · run log}

[TarikGul]

Checked the accounting rather than reading it. One construction site, one increment, one decrement, and everything after guard.connections += 1 is infallible so no error path leaks a slot. The decrement sits under the lock after the closed.swap guard so a double close cannot double decrement, and refuse is a method not a constructor, so there is no unbalanced path to underflow. The FFI closes through LightConnection::close too, so the cap holds there.

Your verification claim holds. I mutation tested both new tests: deleting the decrement fails the cap test, and making a parachain's borrowed relay also spend a slot fails the parachain test. The clippy note checks out as well, provider.rs:221 fires on main too.

One gap inline. Counting in its own field rather than summing added refcounts is the right call and the parachain test documents why.

[TarikGul]

Approving so this is not a blocker. The cap itself is correct and both new tests are pinned.

The Drop nit above still stands, it is a missing test rather than a defect, so worth picking up here or as a follow up.