fix(site): pin legacy feed IDs behind a named base and tighten review follow-throughs

[joeharris76]

Follow-throughs from the adversarial review of #2909 (all accepted, none applied until now):

• website/src/lib/atom.ts: legacy Atom entry IDs now build from a named LEGACY_FEED_ID_BASE instead of an inline hardcoded blog/ segment. Behavior unchanged; pinned by blog-feed.test.ts (19 passed) against the legacy-ID fixture.
• docs/reference/python-api/result-analysis.md: machine identifier 'recurs' (was 'may recur'); tuning-payload sentence reworded to neutral phrasing with identical meaning (consistency is real behavior). Doc snippet output verified True by executing test coverage (test_public_pseudonym_salt.py).
• Allowance scope verified already tight (lost-ID and canonical-link items produce different strings that cannot fullmatch the legacy-only rule); added a regression test pinning that both are rejected by canonical-atom-entry-links.
• Subscriber check: in-repo feed consumers key entries by <id> (site_inventory.py, fixture comparisons); nothing dedups on <link>.

Testing: test_site_parity.py 36 passed; blog-feed.test.ts 19 passed; scoped comment-policy 0 violations; git diff --check clean.