docs: a silent request never gets a rendered error

The failure table put callback and derivation-origin validation outside the single
outcome, as the existing redirect-transport error. For a silent request the
implementation answers `interaction_required` like every other failure, because
rendering a full-page error inside what the user sees as their own app is the
thing this design exists to avoid.

Also gave the two pieces of browser state their storage and their keys. They were
described in a sentence with no table under a Constants heading, which read as the
lead-in to something deleted, and were the only mention of state an implementer
has to reproduce exactly.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: sea-snake

docs/ongoing/silent-reauth-redirect-spec.md

@@ -119,13 +119,13 @@ The same fact makes sign-out propagate. "Sign out of one and the others follow"
 
 ## Failure modes
 
-| Situation                                                        | Outcome                                          |
-| ---------------------------------------------------------------- | ------------------------------------------------ |
-| No session held                                                  | `interaction_required`                           |
-| Session expired, or revoked from another app or from II settings | `interaction_required`                           |
-| Hint resolves to another origin's session                        | `interaction_required`                           |
-| Several sessions and no hint                                     | `interaction_required`                           |
-| Callback or derivation origin fails validation                   | The existing redirect-transport error, unchanged |
+| Situation                                                        | Outcome                                                                                      |
+| ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
+| No session held                                                  | `interaction_required`                                                                       |
+| Session expired, or revoked from another app or from II settings | `interaction_required`                                                                       |
+| Hint resolves to another origin's session                        | `interaction_required`                                                                       |
+| Several sessions and no hint                                     | `interaction_required`                                                                       |
+| Callback or derivation origin fails validation                   | `interaction_required` for a silent request, the existing redirect-transport error otherwise |
 
 One outcome for every session-related case, so a client's fallback is a single branch. That is not to hide anything: the `prompt=none` rules above already bound what it can be used to learn, since it only ever answers for the requesting origin.
 
@@ -141,10 +141,12 @@ One outcome for every session-related case, so a client's fallback is a single b
 | Reason values               | `login_required`, `account_selection_required` | Carried in the error payload. A client may use them to word its prompt; it does not have to branch on them                |
 | Local record expiry margin  | 5 minutes                                      | A record within this of its expiry is not treated as usable, so a chain is never handed over that dies mid-request        |
 
-Two pieces of frontend state this design relies on. The two authorize-URL parameters are
-journalled so they survive a round trip through an external identity provider, and the
-browser id is cached per identity so a returning browser is recognised rather than
-re-registered.
+Two pieces of browser state this relies on:
+
+| State                            | Where                                         | Why                                                                                                 |
+| -------------------------------- | --------------------------------------------- | --------------------------------------------------------------------------------------------------- |
+| The two authorize-URL parameters | `sessionStorage`, keyed per authorize request | They must survive a round trip through an external identity provider, which navigates away and back |
+| The browser id                   | `localStorage`, keyed per identity            | A returning browser is recognised rather than registered again                                      |
 
 ## Requirements