chore(agents): add semantic commit footer and empty-commit rules

A 'Release-As: 2.3.1' footer placed before body prose parsed as body and
was silently ignored; caught only by running the real commit message through
release-please's own parser. Also records that empty commits match no
paths: filter, and that --amend on an empty commit needs --allow-empty.

Author: ChipWolf

home/dot_agents/AGENTS.md

@@ -56,6 +56,8 @@ Always edit the source, not the deployed file. When updating any memory file: re
 - Before committing, run `git diff --staged` and confirm the change is atomic and in-scope. Do not commit unrelated modifications.
 - **Do not leave completed work uncommitted.** Once a task is implemented and verified, commit the in-scope changes before reporting completion unless the user explicitly asked not to commit or the change is only exploratory. If intent is unclear, ask. Treat pushing separately: ask before pushing unless the user already requested it.
 - Commit message format: `type(scope): description`. Types: `feat`, `fix`, `chore`. Check `git log --oneline` to match repo style.
+- **A semantic commit footer only counts in the trailing footer block, and its absence is silent.** Tools that read magic footers out of commit messages (release-please's `Release-As: x.y.z`, `BREAKING CHANGE:`) parse with a conventional-commits parser that only treats a token as a footer when it sits in the final block, after the body. Put `Release-As:` in the first body paragraph with prose after it and it parses as body text and is ignored: no error, no release, just "nothing happened" an hour later. Keep semantic footers last, and verify the *actual* commit message (`git log -1 --format=%B`) against the tool's own parser (release-please uses `@conventional-commits/parser`) rather than eyeballing it. When replicating a tool's detection logic to test, confirm the replica first reproduces a known-good example: if every candidate fails, including the documented one, the instrument is wrong, not the input.
+- **An empty commit matches no path filter.** `git commit --allow-empty` (the documented way to force a release-please version) touches zero files, so a workflow gated on `paths:` will not fire for it and the release never gets built; trigger the workflow explicitly (`gh workflow run`) afterwards. Related trap: `git commit --amend` on an empty commit refuses with `No changes` unless you pass `--allow-empty`, so an amend you believe rewrote the message can leave the original message in place. Re-read the message after amending.
 - After any branch switch (including `gh pr checkout`), verify with `git branch --show-current`. If `gh pr checkout` fails or lands on the wrong branch, use `git checkout <branch>` directly.
 - A stale `.git/index.lock` blocks all git operations. Remove it with `rm -f .git/index.lock` before retrying the blocked command.
 - **Worktree context.**