feat(ci): run this repository's own workflows

[sbaerlocher]

Summary

• arillso/.github had no CI of its own. All 16 workflows were workflow_call-only reusables for consumers; the single check that ran on a PR here came from a pull_request: trigger grafted onto ai-claude-review.yml. This adds the three self-CI workflows sbaerlocher/.github uses, each calling the local reusables via a ./ path so the workflows consumers depend on get exercised before they ship.
• self-merge.yml closes a rollout gap. Tagging was manual and the newest tag was 2026-06-18 — exactly what all seven consumer repositories pin. Everything merged since then, fix: stop expanding caller inputs into run bodies #66 and fix(ci): read review instructions from the base ref #69 included, sat on main unreachable by any tag. The tag now follows the day's latest merge, forward-only, serialised on concurrency: date-tag.
• ai-claude-review.yml loses its pull_request: trigger and becomes workflow_call-only like every other reusable, invoked from self-pull-request.yml.

Workflow-validation skip is not fixed here

An earlier draft of this description claimed moving the trigger would stop claude-code-action from skipping itself on PRs that touch ai-claude-review.yml. That is wrong, and the run on this PR disproves it — Code Review / claude-review reports pass while the log says:

Skipping action due to workflow validation … Exiting due to workflow validation skip

The guard validates every workflow file participating in the run against the default branch, not only the triggering one. This PR modifies the called reusable itself, so it fails validation regardless of where the trigger lives. No review has run on this PR, and none ran on #69 either.

Two separate follow-ups, both out of scope here:

1. Port f618c75 from sbaerlocher/.github ("report a workflow-validation skip as a skip") so a skipped review stops reporting a green pass. Right now a silent skip is indistinguishable from a clean review.
2. Any PR touching ai-claude-review.yml needs human review by construction — the bot cannot review changes to its own workflow before they land on main.

Notes

• enable_yamllint: false in the lint job is deliberate. ai-claude-review.yml:132 carries a 515-char --allowedTools line over the 500-char limit in templates/.yamllint.yml. The list is comma-separated and cannot be folded — YAML block folding inserts a space after each newline, producing entries like " Bash(gh pr view:*)". Fixing it means either restructuring that line or revisiting the limit in a template that consumers inherit; both belong in their own change.
• The three new files are prefixed self- to keep them visually distinct from the reusables and away from the ci-/security-/release- categories documented in AGENTS.md.

Test plan

• actionlint (v1.7.12, container) on all three new files plus ai-claude-review.yml — exit 0, no findings.
• yamllint -c templates/.yamllint.yml — finding count identical to main (8), no new findings introduced.
• Every uses: ./ target resolves to an existing file (5/5).
• --allowedTools line verified byte-identical to main; the diff on ai-claude-review.yml is only the trigger removal and two comment blocks.
• First live exercise of self-pull-request.yml: five checks now run (Lint / Action Lint, Lint / Shell Check, Code Analysis / Analyze Code (actions), CodeQL, Code Review / claude-review) where previously only AI - Code Review did. Lint / YAML Lint correctly reports skipping per enable_yamllint: false.
• Code Review / claude-review reports pass without running a review — see the section above. Not a regression from this change; fix(ci): read review instructions from the base ref #69 behaved identically.
• self-merge.yml cannot be verified pre-merge — the first push to main after merging should create tag 2026-08-07 and point it at the merge commit.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.