A setting the sentinel finds away from its default is the owner's ask (Keep or Put back), never a crew run #2029

Replaces #2021, which was parked twice. A sentinel setting finding (settingsAway in src/crew/sentinel.ts) is a decision only a person can make: keep the setting or put it back. Today handOver labels it P0 Trust and assigns it to the sentinel, so the crew is dispatched on it, cannot change a runtime setting, and parks it twice.

Intent. A setting away from its default reaches the owner as one ask in the inbox, with Keep and Put back, and never becomes a crew run.

Done looks like.

• [ ] The sentinel still files a setting finding, but does not assign it to an agent, so no run is queued. A test in test/sentinel.test.ts asserts that no issue.assigned event follows a setting: finding, and still asserts it for every other finding.
• [ ] The owner's inbox (src/web/studio/asks.ts) shows one ask per open setting finding: the key, the value, the default, and who set it and when. Keep closes the finding with a reason, recorded as kept the way settingKept does. Put back clears the setting on the capacity path, which is recorded and reversible, and closes the finding. Both are same-origin POSTs for a person who writes to the repository. Tested.
• [ ] Only a person's close or comment counts as kept. A close by an agent records nothing in sentinel_kept. A migration removes any sentinel_kept row made by an agent's close, so cells.egress (#2021, closed by the planner) is asked of the owner again. Tested.
• [ ] bun x tsc --noEmit, test/sentinel.test.ts and test/asks*.test.ts pass.

Files. src/crew/sentinel.ts, src/web/studio/asks.ts (a new setting kind), the inbox route that takes the two answers, a migration, test/sentinel.test.ts, test/asks.test.ts.

Risks. Putting a setting back from the inbox must go through the same validation and recording as the capacity page, not around it. Grouping must keep one ask per key.