test(learning): anchor the detector fixture calendar to today

[kavin-114]

Summary

Shard 4 fails on develop and both hotfix lines from 2026-09-06 because the learning-detector fixture dated every row from a literal 2025-09-01, and that morning the oldest Work Orders aged out of the 12-month window that mfg-default-bom-usage scans. Nobody notices in the product; this only unblocks CI. The same commit is cherry-picked onto the open #1142 backports (#1146, #1147), so the hotfix lines receive it there and this PR carries no backport labels.

What changed

• factory._day(ordinal) is now anchor plus ordinal days, with the anchor fixed once per build() at today minus 11 months.
• The Beta go-live burst and the _insert creation fallback ride the same anchor.
• The print-log tests keep their literal days on purpose: they assert exact periods and the watermark and are bucketed by print-log creation, not by these fixture dates. They expire around 2027-03 with the 18-month window and are a separate, pre-existing item.

Risk and verification

• One test-fixture file. The dataset always sits 230 to 335 days back: inside the tightest window with a month of headroom, never in the future, and still older than the engine's 180-day dormant cutoff, which is the age class the literal dates had (test_orchestrator patches around it). Hosted CI is the gate.

Root cause

window_start = add_months(today, -12). The Widget Work Orders sit on _day(0..23) = 2025-09-01..24 and the gate is n_min = 20. On 2026-09-05 the window started at 2025-09-05, leaving indices 4..23 = 20 units, exactly at the gate. On 2026-09-06 it moved to 2025-09-06, leaving 19 units, so reduce_units produced no candidate. The failing run logged rows_scanned=40, raw_candidate_count=0: 19 Widget plus 21 Elec rows.

Four more detectors use a 12-month window (cfg-naming-series, cfg-default-vs-usage, cfg-custom-field-always-filled, role-doctype-routing) and one uses 24; they were on the same slope with more headroom, which is why the fix re-anchors the whole fixture instead of bumping one ordinal.

Pre-merge checklist

ℹ️ A red check only blocks the merge where the branch ruleset lists it as required.
Honoring this checklist is what keeps broken changes out of UAT. See
CONTRIBUTING.md.

• CI is green — the tests check on this PR passes (never merge on ❌)
• Branch is up to date with its base (develop, or version-N-hotfix for a backport)
• New/changed behavior has tests (the coverage gate still passes)
• I self-reviewed the diff
• If the base is version-N: this is the release PR from version-N-hotfix, __version__ is bumped, and release-source is green

https://claude.ai/code/session_01CkvbXsZAizy4UDh9ZWjn51