Call the shared hygiene check beside this board's own gate

[iderex]

Closed unmerged as a duplicate. The survivor is #179, which is open,
carries the same one file, and was opened first.

What this was

.github/workflows/shared-hygiene.yml, calling the shared pull request hygiene
rules in iderex/wache pinned by commit hash with the commit subject rule off,
for #178.

Why it is closed rather than finished

The obstacle it ran into is already measured and written down on #178, and
#179 is where the change waits for the repair. The called workflow
claims the concurrency group pr-hygiene-<pull request number>, which is the
string .github/workflows/pr-hygiene.yml on this board already claims, so the
two runs land in one group and the local gate is the one that dies. On this head
it was cancelled three seconds after creation with no step run and no verdict:

gh api "repos/Flowfin/core/actions/runs?head_sha=5b9c142d1b841a02d3a7e7f8aef43c040117476f&per_page=100" \
  --jq '.workflow_runs[] | select(.event == "pull_request")
        | "\(.name)\t\(.status)/\(.conclusion)\t\(.created_at)\t\(.updated_at)"'
pr-hygiene      completed/cancelled  2026-08-23T13:25:17Z  2026-08-23T13:25:20Z
Shared hygiene  completed/success    2026-08-23T13:25:18Z  2026-08-23T13:25:26Z

gh api repos/Flowfin/core/actions/runs/32642291955/jobs \
  --jq '.jobs[] | "\(.name)\t\(.conclusion)\tsteps=\(.steps | length)"'
Deterministic PR-hygiene checks  cancelled  steps=0

This head declared a concurrency group of the caller's own, and the local gate
was cancelled anyway, which is the same reading already recorded on #178 against
three other placements of that group. So the group the called workflow claims is
independent of its caller, the repair is not available from this board without
editing the local gate to work around a name chosen elsewhere, and it is filed
where it belongs. Nothing above is a new finding and I am not restating the rest
of it here.

The shared side did run green, and its log carries the nine fixture lines and
the line saying the subject rule is off:

gh api repos/Flowfin/core/actions/jobs/97201133391/logs \
  | grep -cE '[0-9]Z fixture ok'
9

The pattern is anchored after the timestamp on purpose. An unanchored count
returns 13, because the log also echoes the lines of the script that print those
fixtures, and 13 would read as four fixtures nobody wrote.

What is not covered

Nothing is merged from this branch and nothing on this board changed. #178 is
still open and its condition is still unmet, for the reason written on it.