The sentinel stops refiling a setting a person kept on purpose; it reports it again only when the value changes #2001

Intent: a setting someone chose and explained is a decision, not drift. The sentinel should only report it again if the value changes.

Why: #1610 was parked twice. On production capacityDefault (src/core/capacity.ts) reads FORGE_CELLS_EGRESS from the environment, so the default there is "report", and the owner set cells.egress to "enforce" on purpose (P0 wants it enforced). Today settingsAway in src/crew/sentinel.ts reports the setting regardless. hunt also files a new issue whenever a closed finding returns. So closing the issue with a reason, as its own "look for" line invites, only brings it back as a new issue.

Done looks like:

• [ ] When a person closes a setting:<key> finding's issue, or comments on it saying why the setting stays, the sentinel records the value and forge_setting.updated_at it was kept at. The record lives in sentinel_finding or a small table beside it, added through the existing migration pattern.
• [ ] While the stored value and its updated_at match that record, hunt files no new issue and leaves no comment for that key.
• [ ] If the value is changed again on the capacity page, the setting is reported again under the usual one-day rule.
• [ ] The issue body's "What to look for" says that closing it with a reason keeps the setting.
• [ ] Tests in test/sentinel*.test.ts: a kept setting is not refiled on the next hunt, and a changed value is refiled. Each test fails without the change.
• [ ] Nothing is changed on the live forge: the stored cells.egress stays "enforce".

Files: src/crew/sentinel.ts, its migration, test/sentinel tests. Risks: other findings (held, ledger, red) keep their current reopen-as-new behaviour; only setting: keys are affected. Brief: a builder who knows the sentinel (sentinel's own area).