test(amazonq): address review findings on the access-blocked observer

[ashishrp-aws]

Targets feature/qdev-signup-message, so #2800 picks these up automatically.

Follow-ups from the review of #2800. No behaviour change for users — one wiring fix and two test improvements.

1. Name the streaming client's middleware

The token client registers its observer with name: 'detectQDevPluginAccessBlocked'; the streaming client did not. Without a name, a second registration stacks another observer instead of replacing the first, which would report the same block twice, and the middleware is anonymous in SDK stack introspection.

2. Assert name uniqueness against the real servers, not the constants

The previous test compared AMAZON_Q_SERVICE_SERVER_IAM_NAME and ..._TOKEN_NAME. That guards the constants but cannot catch the same name being passed to both factory calls — which is exactly the mistake that shipped and caused Duplicate servers defined.

The test now invokes both real exported servers' initializers and asserts the names they actually report are distinct. Verified it bites: making the two names identical fails it (7 passing / 2 failing, versus 8 / 1 with the fix).

Reviewers asked for a composition-level test that walks every server registered by agent-standalone. That is the stronger form and I agree with it, but it belongs in the runtimes app package rather than here, since that is where the composition lives. Raising it separately rather than stretching this PR.

3. Two tests for the streaming observer

These assert the wiring, deliberately not the callback: the existing harness stubs CodeWhispererStreaming.prototype.sendMessage, which bypasses the middleware stack entirely, so a behavioural test written there would pass even if the middleware did not exist. Rather than write a test that proves nothing, they assert what is actually verifiable at this level — that exactly one named middleware is registered on the initialize step, and that the observer property is settable after construction (it must be, since the service manager assigns it later).

Testing

shared group: 337 passing / 45 failing, against 334 / 45 before — the three new tests, no new failures. The 45 are pre-existing and unchanged (utils.test.ts and the onUpdateConfiguration case). tsc and prettier clean.

Review findings deliberately not addressed here

• Observer errors are logged at debug. Two reviewers suggested warn. Left alone for symmetry with the token client, which has shipped that way; changing one and not the other would be worse. Worth doing to both, separately.
• showNotification logs at info when it drops a notification for want of a router. This is in the runtimes package and was one of the three silent failures behind fix(amazonq): pass notification feature to the Q service manager #2796/fix(amazonq): declare serverInfo so notifications reach the client #2797. Belongs in a runtimes change.
• A snapshot assertion pinning the exact server-name strings. The names are embedded in notification followup ids, so a rename strands in-flight followups. Reasonable, but the JSDoc already states the constraint and the value is now asserted via the real servers.