The canary would have gone red every day once the secret expired

[jehrr]

Petr asked whether it is even worth setting the ETSY_CDP_ENDPOINT secret,
given the endpoint dies within a day. Checking the code rather than assuming:
he is right, and the canary was the thing at fault.

test "$code" = "0" failed the job on any non-zero exit. So:

• An expired secret (exit 5) painted the badge red every day until someone
  refreshed it. A credential is not forever — this was going to happen
  whatever endpoint was configured.
• An intermittent block (exit 3) did the same. Measured 2026-09-09/10 on
  one account: a fresh profile served three full pages in the morning, and
  that evening two fresh profiles were refused with t=bv through all their
  retries while a third served a shop front in full, twice. Same code, same
  zone, same URLs.

A check that is always red teaches everyone to ignore checks — worse than
having no check. This repo's own notes say so twice.

Access conditions are now warnings; defects stay red

exit	meaning	badge
0	got in, data checked	pass
3	blocked before parsing	warning — access
5	endpoint refused	warning — access, usually an expired secret
6	partial, usually a mid-run block	warning — access
1	crashed	red
2	the workflow's own arguments are wrong	red
4	served a page and parsed zero rows	red — the tile anchor moved, which is exactly what this canary is for

A warning must not read as a pass either, so each one also writes to the step
summary in words: the canary did not test anything this time. And the
data assertions are now gated on the run having actually got in — on a
blocked run there is no output file, and a missing file would fail for the
wrong reason.

Verified by running it, not by reading it

The real bash block was extracted and executed for every exit code:

exit  0 -> job passes | ok      | tested=true  | summary: no
exit  1 -> job FAILS  | error   | tested unset | summary: no
exit  2 -> job FAILS  | error   | tested unset | summary: no
exit  3 -> job passes | warning | tested=false | summary: YES
exit  4 -> job FAILS  | error   | tested unset | summary: no
exit  5 -> job passes | warning | tested=false | summary: YES
exit  6 -> job passes | warning | tested=false | summary: YES
exit 99 -> job FAILS  | error   | tested unset | summary: no

A test does the same, so this cannot regress.

The README now carries a table of what the badge means on this site —
including that a green badge from a blocked run is not evidence the parser
still works.

566 offline checks.