test(concurrent-keys): integration coverage for view-scoped key rejection

[aaron-zeisler]

Summary

Integration coverage for the view-scoped key rejection added in #795. Stacked on that branch — review #795 first, and this will retarget to feat/concurrent-keys automatically once it merges.

Jira: SDK-2860

Background

#795 proves the filter at the BuildAcceptedSet unit boundary: given params, the right keys land in the accepted set and the right identifiers are reported. That leaves the questions a unit test structurally cannot answer — whether a rejected credential actually fails downstream authentication, whether it really carries no state anywhere in the environment, and whether a live SDK connection on a key that gains a view is genuinely torn down.

These run through the two real harnesses in the existing concurrent_keys_*_test.go family (autoConfTest for the auto-config stream, offlineModeTest for the archive), so the assertions hit actual HTTP endpoints, a real /status response, and live event streams.

Changes

Seven tests, mirroring the four cases named in the ticket:

• Rejection, both sources. A view-scoped SDK key and mobile key fail every SDK endpoint while the anchor and their non-view-scoped siblings keep working, the anchor still opens the single upstream client, and the rejected keys are absent from both the accepted set and the /status sdkKeys[]/mobileKeys[] arrays (asserted by exact count, so a key surfacing under an unexpected obscured value is still caught).
• The designated-key carve-out, both sources. A marker on the anchor or primary mobile key is ignored rather than fatal: the environment comes up normally, every key still authenticates, no error is logged, and the ignored marker is reported as such.
• Mid-session view acquisition. On the offline path (which uses a real SDK client that serves stream data), a connected SDK on a non-anchor key has its stream closed when the key gains a view, stops authenticating, and is re-admitted when the view is removed again — the filter is stateless, not a one-way latch. Covered for both an SDK key and a mobile key. The auto-config equivalent holds an open stream on the anchor and asserts the revocation leaves it undisturbed.
• No misleading WARN on malformed payloads. A payload that is both malformed and carrying view-scoped keys logs the malformed error and stays silent about the view-scoped ones, since the handler discarded the payload and never rejected anything.

The ingestion WARN is also asserted to fire exactly once per payload. That is what makes the decision to keep StreamManager.validateCredentialPayload silent regress loudly — it runs on every environment of every payload, so logging from there would double every message.

Every test was mutation-checked: disabling the non-anchor filter fails four of them, disabling the designated-key branch fails the other two, and the malformed-payload case fails only when both of its independent defenses are broken.