docs(email-security): the historical backfill is judged now, and still acts on nothing

[maximelb]

HOLD — merge with the production release. These docs describe behaviour that ships with legion_mailsec #100 and is deployed to the Experimental cluster only. Do not merge until Email Security is released to production.

What was wrong

The docs said, in four places, that the connection bootstrap is metadata-only and "computes no verdicts and performs no actions". The first half of that is no longer true.

The 14-day historical walk now judges the mail it indexes, with the same managed pack, the same customer dr-mail rules and the same policy thresholds live mail is judged with. So a customer's queue has real verdicts on their first day, the raw copy and the judged model are stored on the normal retention lanes, a flagged message gets the same 400-day evidence row, and a hunt or a rule backtest has a fortnight of that customer's own mail to run against — instead of a screen of unknown.

The second half is unchanged and is the part that needed saying more clearly, not less: backfilled mail emits no telemetry and acts on nothing. No EMAIL_MESSAGE, no EMAIL_VERDICT, no policy automation, no remediation, no detonation, no user-report processing, and no contribution to the time-to-verdict percentile.

What is here

• pipeline.md — a new ## The historical backfill section carrying the contract and the reasoning in one place: mail delivered eleven days ago has already been read and filed by the person it was addressed to, so quarantining it now is a surprise, and replaying a fortnight of it into a customer's D&R rules on the day they switch the product on is a denial of service on their own alerting. Also states what backfilled mail does feed (sender profiles including the flagged counter, and campaign clustering), that the walk is paced so it cannot take capacity from live mail, and that mail arriving during the walk is ordinary live mail.
• messages.md — ### Which lane judged it, documenting the drawer's new judged_via field and the one screen where the distinction matters: a backfilled message can show a malicious verdict beside an empty action timeline, and without this an analyst's only readings are "our telemetry is broken" or "somebody suppressed this". Absent/null is documented as unknown, never live.
• api-reference.md — message.judged_via on GET /messages/{msg_uuid}, with the same absent-is-not-live warning.
• getting-started.md, index.md, providers.md — the three stale "metadata-only" claims corrected, including the backfill_days table row.
• pipeline.md's time-to-verdict exclusion note now distinguishes the historical backfill (which emits nothing, so it never enters the population at all) from an incident backfill and the emission sweeper's repairs (which do go back through the ingest path and are excluded by lane).

Anchors

Checked by hand, both directions:

link	target
messages.md#which-lane-judged-it	pipeline.md:306 → messages.md:107 ### Which lane judged it
pipeline.md#the-historical-backfill	messages.md:122, api-reference.md:49, pipeline.md:369 → pipeline.md:267 ## The historical backfill

No metadata-only, metadata only, no verdicts or not judged string remains anywhere under docs/email-security/.

[maximelb]

/lc-review

[maximelb]

HOLD — do not merge yet. Approved and green (including check-links, which validates the two new anchors), but this describes behaviour that ships with legion_mailsec #100 and is deployed to the Experimental cluster only. Merge it with the Email Security production release, not before — the public docs would otherwise describe a backfill that judges to customers whose region still runs the metadata-only walk.