feat: distinct sign-in error when Q Developer access is blocked (#571)

• feat: distinct sign-in error when Q Developer access is blocked

Amazon Q Developer stopped accepting new Builder ID accounts. Such an account signs in successfully – sign-in is OIDC and is never gated – and then finds Q silently non-functional, because every Q request from that identity is refused and the refusal surfaces as if it were a chat reply. No explanation, and nothing the user can act on.

Only the language server observes the refusal. The service gates on the User-Agent of the shared language server, so the plugin’s own SDK calls are allowed unconditionally and there is no client-side signal to classify. The server reports it over the existing notification channel, so this change teaches the plugin to listen.

• Declare aws/window/showNotification on the client and act on it.
• Advertise window.notifications. Without it the runtime builds no notification router and drops the notification silently – no error and no log, which is the failure mode that cost the most time on the VS Code and JetBrains ports.
• Identify the notification by id, never by title. The runtime’s router rewrites the declared id into base64 of {“serverName”:…,”id”:…}, so the raw id never arrives, and a title match would sign out a working user the first time an unrelated error reused the title “Amazon Q Developer”.
• Add QDevAccessBlockedState and resolve it in ViewRouter ahead of the logged-out state. Reacting to the refusal signs the user out, so the two states are always true together; checking logged out first would show the ordinary login view and lose the explanation.
• Add QDevAccessBlockedView, following ReauthenticateView, explaining what happened, pointing to Kiro, and offering a route back to sign-in for pre-cutoff Builder IDs.

The screen carries its own copy rather than displaying the service’s message: that message is one sentence written for an API consumer and does not say what to do next. Consequently the dates on the screen are product copy from the public announcement, not values reported by the service.

Ports the behaviour already shipped in VS Code (aws/amazon-q-vscode#159) and JetBrains (aws/amazon-q-jetbrains#120).

Verified: mvn -B package on Corretto 17 – BUILD SUCCESS, 508 tests, 0 failures, including 7 new classifier tests and ViewRouterTest at 14/14 with 2 new routing tests.

• fix: seed the blocked state so the view router can emit at all

Found in Windows testing: the Amazon Q panel rendered permanently blank. The plugin resolved and the language server launched, but no view was ever selected.

ViewRouter combines its state streams with combineLatest, which emits nothing until every source has emitted once. Every pre-existing state is seeded during startup by the service that owns it, but QDevAccessBlockedState has no owning service: it is only posted when the language server reports a refusal, which for almost every user is never. The silent stream starved the combined stream, so the router never published a view and the container had nothing to render. The unit tests missed it because they hand-seed all streams.

Seed NOT_BLOCKED with startWithItem at the point of combination, so the stream can never starve regardless of how the observable was injected. The clearing test now asserts the blocked -> login ordering rather than a single post, since the seed legitimately posts the login view once before the block arrives.