fix(ci): stop list_groups sweeping on an unverified parse

[naxty]

pre-cleanup no longer dies — but it now does nothing for 50 minutes, and reports
success-shaped output while doing it. This makes that impossible.

What is happening on main right now

From the run at 08:56Z:

clean-environment.sh: command failed at line 218 (exit 1): GROUPS=$(list_groups)
Pass 1 - found:
  1001
  deleting 1001
    already gone
Waiting up to 25m for deletion to complete...
  204 group(s) still deleting, waiting...      ← ×50
  ...then Pass 2 repeats the whole thing

list_groups returned the single token 1001 instead of 204 group names. The
script asked ARM to delete a resource group called 1001, got
ResourceGroupNotFound, counted that as "already gone", then sat in wait_gone for
two full 25-minute budgets while every real group survived untouched.

The Azure activity log confirms it independently: four resourcegroups/delete
events, all against rg=1001, all Failed.

Consequence: pre-cleanup can never pass while groups survive, so
conformance-tests never runs. #152 is hard-blocked on this.

Two defects made that possible

1. Every failure in the parse pipeline was swallowed.

| jq -r ... 2>/dev/null \
| grep -E "^${TEST_PREFIX}[A-Za-z0-9._-]*$" || true

jq's stderr went to /dev/null and the grep carried || true, so a broken parse
was indistinguishable from an empty subscription — and "no test groups" is a normal
exit 0. That is exactly how a sweep silently does nothing while 204 groups keep
billing.

Now: jq's stderr is not discarded, and the function proves its parse rather than
assuming it. It asks how many groups az group list reported (jq length) and
compares that against the number of names actually extracted. A mismatch prints the
first 200 bytes of the body plus the extracted names, and is fatal.

2. grep was in the trust path.

No regex anchored on ^${TEST_PREFIX} can return 1001, yet 1001 reached
az group delete. Whatever the mechanism, grep is the link that provably
misbehaved, so it is gone: the prefix test is now bash's own
[[ "${name}" == "${TEST_PREFIX}"* ]] — no external binary, nothing on PATH that
can shadow it, exact. The destructive guard is preserved: only names the function
re-verified itself are ever printed, which is what kept 1001 merely useless rather
than catastrophic.

The flag is a file, not a variable

Callers invoke this as GROUPS=$(list_groups) — a subshell — so a variable set
inside the function is discarded on return. The first cut of this patch made exactly
that mistake and exited 0 on a detected parse failure. It is a flag file now,
cleaned up on EXIT.

Verification

Against stub az/jq, both cases asserted:

Case	Result
Healthy — 4 groups, 2 prefixed, az group list exits 1 with valid JSON	proof does not fire; debug: az reported 4 group(s), parsed 4, matched prefix 2; only the 2 prefixed groups reach az group delete — production-rg and a decoy group literally named 1001 are both spared
Mangled — jq length says 3, name extraction yields 1001	detected, body and names reported, exit 1: "could not parse the resource-group list; nothing was swept. Treat this as a failed sweep, not a clean subscription."

What this does not claim

It does not explain why CI's pipeline produced 1001. The pattern is odd — the
same function returns correct results when called later in the same run (wait_gone
counted 204 correctly) — and I could not reproduce it faithfully, because this
workstation's shell rewrites command output including values inside pipelines, so an
untraced local run of this script cannot be trusted at all. The new debug line and
the un-swallowed jq stderr exist to name the mechanism on the next real CI run.

What it does guarantee: the failure can no longer be silent, and can no longer burn
50 minutes deleting a group that does not exist.

This must land on main to be exercised — a PR touching only scripts/ resolves
to an empty conformance scope, which skips pre-cleanup entirely. That is also why
this PR's own CI will not prove it.