[Flotapponnier]

the guard worked and the carry put the refused value back

Verified the six audit fixes against the published blob rather than the
logs, and five landed exactly on the numbers the audit said they should:

success    100 at n=56, where it read 81.8182 at n=88
headline   quicknode 91.07, chainstack 94.64, getblock 76.79, which is
           the stated seven-cell method to the decimal
freshness  3.6 to 3.8 h, the oldest capability stamp, instead of being
           pinned near one hour by the hourly eth_call stamps
windows    dwellir 500 where it read 100, bound label applied
Solana     the cross-tab view is gone

The sixth did not. chainstack still published minus 1.84 ms on the work
term, and the reason is the interesting part: its valuesMeta carries
staleSince. The > 0 guard from #3420 was working, chainstack was
correctly absent from the fresh query, and the PANEL CARRY in the worker was
resurrecting the value the panel had refused.

From the merge, a query that filters deliberately and a query that failed
look identical. The carry exists for the second and cannot see the first.
This bench sets expected_freshness_seconds to 86400, which is right for a
capability probed every six hours and is also the carry ceiling, so an
impossible number would have sat first on a lower-is-better view for a day.

So the spec says which of the two it is. carry: false on a panel means a
missing value is a statement rather than a gap, and the worker leaves it
missing. Default behaviour is untouched: the carry is still the protection
against a Prometheus hiccup, which is the reason it exists.

Three tests, one per case, and a mutation that drops the flag check fails
the first. The other two pin that nothing changed for panels that do not
declare it.

261 specs valid, tsc clean, 873 tests pass.