tracked_render_warning: tell projects that already committed _bmad/render/ to untrack it

[pbean]

Context

Follow-up from #405 / PR #406. Cut from that PR's review round.

0.9.1 keeps the renderer's published output out of new commits: init writes _bmad/render/
into .gitignore, and provision_worktree adds a /_bmad/render/ git exclude whenever the
worktree has a _bmad/ at all. Both only help going forward. A project that already committed
_bmad/render/ — before 0.9.1, or before it gitignored _bmad/ — keeps churning it into every
story commit, because a tracked path ignores .gitignore and info/exclude entirely.

The churn is not cosmetic. Every snapshot dir is named for a hash of the absolute project
root plus a generation hash of the renderer, its sources and the resolved config
(render_skill.py), so a committed tree grows a new directory per machine, per checkout path,
and per upstream renderer bump — and under isolation = "worktree" the worktree's own absolute
path differs from the main checkout's, so every isolated run adds one.

Proposal

A tracked_render_warning validate check: warn when git ls-files _bmad/render is non-empty,
with the remediation

git rm -r --cached _bmad/render && git commit -m "chore: untrack rendered skill output"

Severity warning. This is commit hygiene, not a HALT — nothing about a tracked _bmad/render/
stops a session from running, which is why it was cut from the hotfix rather than shipped with
the two HALT-shaped renderer warnings.

Notes

• Register the id in checks.VALIDATE_CHECKS, or the existing subset tests fail.
• The probe is a git call, so it must go through the _run_git chokepoint and degrade quietly
  in a non-repo project (validate runs there today and must keep passing).

[coderabbitai]

🔗 Related PRs

#152 - fix(worktree): detach kept worktree so branch_per=run survives a kept failure (#138) [merged]
#155 - fix(worktree): survive the renderer-era bmad-dev-auto (BMAD-METHOD #2587/#2588) [open]
#182 - fix(worktree): degrade post-merge teardown failures instead of crashing the run (#139) [merged]
#264 - ci(pyright): adopt basic-mode type check over src/bmad_loop [merged]
#373 - fix(install): guard the worktree exclude's filesystem tail (#359) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[pbean]

Shipped in dac373b on hotfix/0.9.1-build-auto (PR #406). Closing.

The mechanism is the one proposed — git ls-files _bmad/render through the _run_git chokepoint, severity warning, quiet degrade outside a repo — with the name changed:

• Check id is git.render-tracked, not tracked_render_warning. checks.py:32-36 documents ids as <area>.<check> and every existing id obeys it; a bare noun would have been the only exception. Registered in checks.VALIDATE_CHECKS (checks.py:52), so the registry assert at checks.py:106 and the emitted-ids subset test at tests/test_cli.py:3855 both enforce it.
• The probe reuses verify.path_tracked rather than adding a call. It was already on the chokepoint, which is what the issue's note asks for. The non-repo degrade is except verify.GitError: pass — skipped, not a fabricated ok, so validate in a non-repo project keeps passing exactly as before.
• Remediation is the proposal's git rm -r --cached _bmad/render, with the follow-up commit stated in prose ("and commit once to stop committing rendered skill output") rather than as a second shell clause.

One thing landed alongside it that the issue did not ask for: install.RENDER_DIR_NAME / RENDER_DIR_REL now back all four spellings of the render directory that were previously written out by hand — the seed exclude off the bare name, and the gitignore line, the git exclude and this check off the rel — so they cannot drift apart.

No new policy fields, so #156's "every new policy field lands in settings core.toml" rule has nothing to satisfy here.