fix(email): unbreak the specification.html drift guard on main

[itomek]

Main's email test suite has been red since #2082 landed this morning, so every email PR now opens onto a failing suite and a release cut from main inherits it. #2082 added a drift guard asserting `specification.html` is a pure render of `spec_html.py` — but the artifact already carried a hand-added "Context-window envelope" section (from #2072) that the generator never emitted, so the guard failed on its first run and every run since. This makes the generator own that section (bounds read from the `context_budget` constants rather than hand-typed), which fixes the guard and means a future regeneration can't silently delete the section — the thing #2082 was written to prevent.

Extracted from #2088 so the release isn't gated on that PR's hardware validation.

Evidence

Before — the guard cannot pass on main, because the generator does not emit what the artifact contains:

$ git show origin/main:.../spec_html.py       | grep -c "Context-window envelope"   → 0
$ git show origin/main:.../specification.html | grep -c "Context-window envelope"   → 1

Main CI agrees (run on e65e8799):

hub/agents/python/email/tests/test_spec_html_artifact.py::test_committed_spec_html_artifact_is_up_to_date FAILED [ 95%]
E   AssertionError: specification.html is stale — it has drifted from spec_html.py.

After — on this branch:

$ python -m pytest hub/agents/python/email/tests/test_spec_html_artifact.py -q
....                                                                     [100%]
4 passed in 0.72s

The regenerated artifact diff is 3 lines: the section is now generator-emitted, and its stale "no committed artifact carries that stamp yet" claim is corrected (the baseline has been ctx-stamped since #2089).

Test plan

• `pytest hub/agents/python/email/tests/test_spec_html_artifact.py` — 4 passed (was 1 failed on main)
• `python -m gaia_agent_email.spec_html` regenerates byte-identically (guard is self-checking)
• CI: Email Agent Unit Tests green on this branch (red on main)

[github-actions]

Verdict: Approve ✅

This unbreaks the email test suite on main. The specification.html drift guard from #2082 was failing because the artifact carried a hand-added "Context-window envelope" section the generator never emitted. This moves that section into the generator (reading the token bounds from the context_budget constants rather than hand-typed numbers), so the guard passes and a future regeneration can no longer silently delete the section — exactly what the guard was meant to protect.

I couldn't run pytest in the review env (no pydantic/pytest installed), but I verified the fix by hand: the generated section and the committed artifact match, the token bounds render from the real constants, and the file's trailing-newline change lines up with the generator output. Scope is clean — two files, both required, no drive-by changes.

🔍 Technical details

Verified

• The "Context-window envelope" block now lives inside the body = f"""…""" render in spec_html.py:966-986, interpolating {CONTEXT_TARGET_TOKENS:,} / {CONTEXT_MAX_TOKENS:,} from context_budget.py:22-23 (16384 / 32768).
• The committed specification.html:396-397 carries the rendered values 16,384 / 32,768, matching the constants — so the generator is genuinely the source of truth now.
• check_artifact() (spec_html.py:1031) does an exact == compare against the render; the f-string ends </html>""" with no trailing newline, which is consistent with the \ No newline at end of file change to the artifact.
• The usage field description delta in the artifact (specification.html) comes from the TriageUsage contract field (already updated in fix(email): eval-pass follow-ups — ctx-stamped baseline, refresh limit, usage aggregate #2089), picked up by regeneration — consistent with the artifact having been stale in two ways on main.

🟢 Minor (optional, out-of-diff — not blocking)

• contract.py:526 hard-codes "16K target / 32K max" in the usage field description, while the section this PR adds derives the same bounds from CONTEXT_TARGET_TOKENS/CONTEXT_MAX_TOKENS. If those constants ever change, the generator-owned section updates but that hand-typed string won't — a latent drift point adjacent to this PR's goal. Pre-existing and outside the changed lines, so fine to leave; worth a follow-up to derive it from the constants too (e.g. {CONTEXT_TARGET_TOKENS // 1024}K target / {CONTEXT_MAX_TOKENS // 1024}K max).

Strengths

• Right fix for the right reason: makes the artifact a pure render instead of muting the guard, preserving the anti-silent-deletion invariant fix(email): guard specification.html against generator drift #2082 introduced.
• Bounds sourced from the context_budget constants rather than duplicated literals — the section can't drift from the real budget.
• Tightly scoped and self-checking; extracting it from fix(email): condense bulk-triage result envelope to fit the 16K ctx budget #2088 to unblock the release without waiting on hardware validation is the correct call.