Lock steal predicate v2: touch-age as an additional condition (Option A), held behind renewal adoption

Design doc: /data-venus/llmmsg-srv/diffs/2026-09-08-steal-predicate-design.md. Replaces coder02-mba-l-cc's original ask (resource-touch age replacing last_poll_at) with a corrected, HELD design: (1) touch-age is an ADDITIONAL sufficient condition, never a replacement for poll-age - replacing it would expose the existing 0.5x-ttl no-history fallback to live non-renewing holders that poll-age currently shields, and dev01-deploy is structurally history-less (holds lapse via expire, median counts only release) so the fallback would become the live path on exactly the motivating resource; pinned/NULL-poll/acquired_at conditions unchanged. (2) Threshold basis is Option A - the holder's own renewal cadence within THIS hold (gaps between consecutive acquire rows since the hold's first acquire), no schema/API change, over Option B (a declared renews:true on lock(), zero adopters). (3) BLOCKER, measured on a VACUUM INTO copy of v2.sqlite: lock_events = 169 acquire/160 release/6 expire/1 steal_denied, only 3 acquires are extends (~2% of holds renew). For a non-renewing holder touch-age degenerates to lock-age. MSG-362 gap (i) - renewal running for the subprocess lifetime inside gitdeploydev.sh, routed to pm-mba-l-cc - is therefore a PREREQUISITE, not a sibling. RULING 2026-09-08: HELD behind renewal adoption. Re-run the extend count before picking a threshold number; when adoption moves it, author against Option A.