lock(): return the resource's median hold time on the 409 and in the free-notification DM

REQUEST (coder02-mba-l-cc DM, 2026-09-08): the 409 lock_held payload and the free-notification DM should carry the resource's own median hold time, so a waiter can decide to wait or go do something else without asking the holder. CURRENT STATE. stmtLockMedianHold (hub.mjs:2743) and stmtLockLastTtl (:2761) already exist and are already correct against the extend path - the median pairs each release to the EARLIEST acquire since that resource's previous release, because a same-holder re-acquire writes a second 'acquire' row (:2777) and stmtLockUpsert never moves acquired_at. Both statements are read at exactly ONE site today: the steal-eligibility test at :9140-9146. Nothing on the ordinary contention path reads them. The 409 at hub.mjs:9055 returns { holder, acquired_at, expires_at, notify_on_release, waiting_for }. expires_at is NOT a hold estimate - after any extend it is claim-to-latest-renewal and grows without bound, so a waiter reading it as 'time remaining' is misled in the worst direction on exactly the longest jobs. The free-notification body in lockNotifyWaiters (:2774) reports how long the waiter waited but says nothing about how long the next hold is likely to run. SCOPE. 1. 409 lock_held payload: add median_hold_s (stmtLockMedianHold, null when the resource has no completed release history) and last_ttl_s (stmtLockLastTtl, the fallback - a TTL VALUE, never a timestamp span). Both nullable; a first-ever contention on a fresh resource returns nulls and the caller must render that as 'unknown', not 0. 2. lockNotifyWaiters DM body: one line naming the same two numbers for the resource just freed. 3. Shim: surface both fields on the lock() error path so a client sees them without reading raw JSON. 4. Optional, PM's call: same two fields on GET /locks rows. CONSTRAINTS. - Read-only addition. No schema change, no new statement, no change to acquire/release/steal/expiry semantics. - Zero-median trap: a resource whose only releases were instant returns median 0. 0 must not render as 'free soon' and must not feed any threshold - it is only a display value here, and the steal path's existing handling at :9146 is untouched. - Do not compute the median inside the lock transaction; both reads are outside it, as at the steal site. - The 409 stays free of a room line (:9049) - contention must not spam the room. VERIFY. a. Fresh sqlite, resource with no history: 409 returns median_hold_s null, last_ttl_s null; DM says unknown. b. Resource with three completed acquire/release cycles: median_hold_s equals the middle span, hand-computed. c. Same as (b) but with two extends inside the middle hold: median is UNCHANGED (proves the earliest-acquire pairing survives the second 'acquire' row). d. Resource with acquires but no release yet: median null, last_ttl_s equals the ttl of the newest acquire. e. Waiter DM on release carries the numbers and the existing not-a-reservation wording. f. Author-side: git apply --check, node --check, boot on a spare port against a fresh scratch sqlite, curl each case.