Let the manual Claude review actually run

[l1a]

Description

v0.6.17 disabled automatic Claude review by commenting out the pull_request trigger and
setting if: false on the claude-review job. The trigger alone already achieved that — but the
guard also applied to workflow_dispatch, which was kept.

So gh workflow run claude-code-review.yml started a run, skipped the job, and reported success
having reviewed nothing. A green tick, no review.

That is the exact failure this repo's tooling exists to refuse, and it is the one
rusticprofile recorded twice about this very action — its 0.0.11 and 0.0.14, both about a
review job going green without reviewing, which is why its workflow now writes its outcome to the
step summary. "Dispatch is available but silently inert" is worse than either honest alternative:
working, or absent.

Nobody had been bitten, which is why it survived — the dispatch had never been used. Every run of
that workflow in its history is a pull_request event predating v0.6.17.

Automatic review stays OFF

Only the job guard is removed. The pull_request trigger remains commented immediately above it,
so per-PR review is still two uncommented lines away, and this PR should show no claude-review
check. To review on demand:

gh workflow run claude-code-review.yml --ref <branch>

The diff is one line deleted plus a comment explaining why there is deliberately no guard there —
because the next person tidying this file needs to know the omission is the point.

Found while auditing the three repos' workflows against each other, which is the same cross-repo
comparison that surfaced the nushell completion path in #191.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature
• Breaking change
• This change requires a documentation update

How Has This Been Tested?

• The diff is exactly one line removed (- if: false), verified with git diff --numstat; the on: block is byte-unchanged, so automatic review cannot have been
  re-enabled by accident.
• This PR is the negative control: if the change had touched the trigger, a claude-review
  check would appear here. It should not.
• just pr green: fmt, clippy --workspace and --features graphics, 69 + 114 + 15 tests,
  man page regenerated at retch 0.6.22, audit advisory-only.
• Opened with just open-pr — the recipe fixed in Make the pre-PR gate answerable; open-pr now pushes #192, dogfooding the auto-push on a branch
  that had no upstream.

Not tested: that a dispatched run now completes a real review. That needs a working
CLAUDE_CODE_OAUTH_TOKEN, and the token's failure mode is exactly what v0.6.17 was reacting to.
If it is still bad, the dispatch will now fail loudly instead of passing silently — which is the
point of the change, but worth saying rather than implying the review itself is verified.

Backup safety

n/a — CI configuration only.

Checklist

• Style, self-review, comment explaining why the guard is absent
• Documentation updated — NOTES.md release entry
• just man re-run after the bump and committed
• No new warnings
• Version bumped 0.6.21 → 0.6.22 (patch)
• No failure mode introduced can degrade silently — this removes one; a dispatched run now
  either reviews or fails, rather than reporting success for a skipped job

Wiki not updated: §4.8's pages cover config/theming, workspace architecture, and just
recipes/build prerequisites/the PR-merge workflow. A GitHub Actions workflow guard is none of
those.