A shared ?sig= link silently matches nothing once the environment list changes

[gaurav]

The drift panel groups results by their outcome pattern and links each pattern into /results/ as ?sig=…. The signature is positional — one character per environment, in DEPLOYMENT_ORDER — so it only means anything against the environment list it was built for.

Add a target to targets.ini, or remove one, and every previously shared ?sig= link silently matches nothing. Not the wrong rows: no rows. The page renders an empty result set with the filter chip showing, which reads as "nothing is in this state any more" rather than "this link is from a different shape of report". A link shared in Slack a month ago is exactly the case that hits this.

Worth fixing because the drift panel's whole purpose is producing links people pass around.

Options, roughly in order of effort:

1. Carry the environment list in the link (?sig=…&sigenv=exp,dev,ci,ci-es,test,prod) and, when it doesn't match the current report, say so where the empty result set would otherwise be: "this link was built for a different set of environments (…), which no longer matches this report."
2. Show the environments a signature covers in the drift panel itself, so the meaning of the pattern is visible before anyone copies it.
3. Make the signature self-describing — keys rather than positions — at the cost of a longer URL.

(1) is the smallest change that turns a silent wrong answer into a legible one, and is probably enough on its own.

Deliberately not done in #120: it needs a call on how the mismatch is presented, and it changes the semantics of a shareable URL, so it wants its own review rather than being folded into a redesign.

[gaurav]

A second, narrower way a shared /results/ link goes stale, noted while reviewing #120 and left unfiled because it belongs next to this one rather than on its own.

?page= is clamped for rendering — currentPage caps page at pageCount — but the clamp is only written back to the URL on a user edit:

// Clamp before writing: ?page=9999 on a three-page result set renders page
// ...
if (this.page !== this.currentPage) this.page = this.currentPage;

That runs in writeUrl(), which fires when a filter changes. So opening ?page=9999 on a three-page result set renders page 3 correctly, but if you copy the address bar without touching a filter first, you pass on ?page=9999 again. The page you send someone is not the page you were looking at.

Same family as this issue: a URL that means something different to its recipient than to its author, and fails quietly rather than visibly. Different mechanism, though — the ?sig= case matches no rows, whereas this one silently shows the last page. Both are the drift panel's and the filter bar's shared premise that these links are worth passing around.

Cheap fix if (1) above gets done anyway: clamp on load as well as on edit, once the report has arrived and pageCount is real. The existing comment says why it cannot happen at readUrl() time — the report has not loaded, so pageCount is not yet known — so it wants a watcher on the report rather than a line in readUrl().

Not urgent on its own; worth folding in when someone is next in this code.