dev: generated checklist of DF defect mitigations for release review

[Alistair-Afton]

Summary

DFHack works around a number of defects in DF itself, and those mitigations may need adjusting or removal when Bay 12 ships a fix. This PR adds a lightweight, self-maintaining checklist for that review:

• DF-MITIGATION: comment marker convention — mitigations are tagged where they live in the code, so the checklist can't drift away from the implementation. New mitigations get marked as they're added; removing one removes it from the checklist automatically.
• ci/list-df-mitigations.py — generates a markdown checklist from the markers. The fix/* scripts (and fix-ster/fixnaked) are included automatically since they are all DF bug mitigations by definition; their descriptions come from the docs' :summary: fields.
• Watch DF Releases workflow — when it detects a new DF build, it now checks out develop (with submodules) and appends the checklist to the job summary. This gives the release coordinator a "soft reinvestigate" signal on every new release, using nothing but free-tier Actions features.
• Docs — the convention is documented in Contributing, and release-process.rst gained a "New DF releases" section describing the review step.
• Seed markers on the mitigations I could identify confidently (reclaim site_id fallback, DF bugs 1416/1871/6330/6273/12672/12721, slab category, caged pets, dismissed viewscreens). More can be marked incrementally.

Sample generated output (current tree):

### Code sites
- [ ] `library/modules/Buildings.cpp:131`: monitor works around DF bug 1416 ...
- [ ] `library/modules/World.cpp:221`: reclaimed forts lack site_id until first save (#5716)
- [ ] `plugins/tweak/tweaks/reaction-gloves.h:1`: workaround for DF bug #6273 ...
...
### `fix/*` scripts
- [ ] `scripts/fix/occupancy.lua`: Fix phantom occupancy issues.
- [ ] `scripts/fix/general-strike.lua`: Prevent dwarves from getting stuck and refusing to work.
... (~30 entries)

Open questions for reviewers:

• Marker name (DF-MITIGATION:) — happy to change to whatever the team prefers.
• Should the checklist also be posted somewhere more visible than the job summary (e.g. appended to the Discord ping or a pinned issue)?
• If a mitigation ever becomes automatically testable, the checklist format leaves room to note that per entry.

Test plan

• ci/list-df-mitigations.py runs locally and produces the checklist (10 code sites + 31 fix scripts)
• Workflow YAML parses
• Lint clean on touched Lua files
• Workflow step itself only executes when a new DF build is detected (guarded by if: env.BUILDID)

[quietust]

Not sure this is really a mitigation, since what's happening here is that DF ignores the color values we're passing, but we still pass them because eventually it will start respecting them again. Also, this technically applies to the color field too, not just bright (which this new comment incorrectly states).

That being said, once it does get fixed, we'll want to remove these comments, so perhaps this still serves a purpose.

[Alistair-Afton]

Good catch. folded the pre-existing color comment into the marker so it covers both fields, and updated the convention doc to clarify that markers are also appropriate for sites whose behavior merely depends on a defect (like this one, the point is flagging it for review on new DF releases, whether or not code needs to change). Pushed as 6b401ab.