fix(distribution): let the version pins survive a change of quoting

[yusuf-gundogdu]

TrueNAS started writing the image tag as tag: "0.17.0@sha256:..." where it had written it bare. The pattern in channels.yaml did not allow the quote, so truenas-scale reported UNKNOWN on every run instead of a version, and it had been unmeasured for weeks before anyone looked. The catalog is in fact on 0.17.0, so nothing was wrong except our ability to see it.

Nothing was going to catch that. strictFailures only covers local_file channels on sla: every_release, which is one channel out of forty, so a remote pin that measures nothing fails nothing. The weekly report prints an UNKNOWN row into a job summary and stops there: no warning annotation, no non-zero exit, no count.

Five more pins read a field whose spelling the upstream owner can change the same way:

• kubero and truenas-scale share the shape that broke. Kubero writes the tag bare today, so it kept working by luck.
• caprover-official is the mirror image: it required a single quote, so it would have gone blind the moment that template was written with double quotes or none. That template was edited upstream this week.
• yunohost required a ~ynhN suffix as well as a double quote, so a packaging-only change to the suffix would have blinded it.
• homebrew spelled the gap as one literal space while every other pattern used \s, so a formatter run that made it two would have been enough.
• helm assumed a double quote around appVersion. It is the one channel --strict protects, so it would have been caught, but there is no reason for it to be the exception.

Each pattern now accepts every spelling its own format allows. Five read the value bare, single-quoted or double-quoted. Homebrew keeps the quote mandatory, because version 0.17.0 is not valid Ruby and accepting it would only widen the pattern towards matching something that is not the version; what it gained is any whitespace before the quote.

Only truenas-scale was actually broken. The other five read the same versions before and after, so for them this is hardening rather than repair: helm 0.17.0, homebrew 0.17.0, yunohost 0.17.0, caprover-official 0.16.2 and kubero 0.9.27, the last two being the real drift they were already reporting.

Two tests come with it. Both read the shipped inventory rather than a fixture, which is the point: extractPin was always capable of reading a quoted value, and the patterns were not, so a fixture test would have passed throughout. One asserts each of the six reads every spelling its format allows, including the whitespace variants for Homebrew. The other pins the digest case, where the capture has to stop before the @ and must not wander into the container_utils_image tag two lines below. Both fail against the patterns this replaces.

Checked locally: format, lint, typecheck, distribution:matrix --check, channels:showcase:check, readme:check, security:check all clean, the five suites that read channels.yaml pass, and GITHUB_TOKEN=... bun run distribution:check reports zero UNKNOWN with truenas-scale at OK 0.17.0.

One thing this does not fix. The reason a blind channel can sit unnoticed is that --strict ignores every remote pin, and the weekly workflow does not pass --strict anyway. Making "I could not measure this" fail something is a change in what CI is allowed to block on, so it is not in here.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud