test: characterize calendar cryptographic verification (Issue #1, stage 1)

[thunder-detector]

Refs #1. Draft; tests and diagnosis only. This does not resolve the issue.

This first stage adds synthetic baseline fixtures and a corrected diagnosis
against f332c8bf873d2cfa4314d4f155d1acc2b3af0e42, with the existing
go-crypto v1.3.0 dependency unchanged. PR #2 remains independent.

What this establishes

• readEventCard already drains UnverifiedBody. Generated MDC/SEIPDv2-AEAD
  corruption is rejected before ICS merging; the commented-out second drain
  does not establish a disabled MDC check. Calling Close() on that
  io.Reader, or passing decoded binary to the armored signature verifier,
  would not be correct fixes.
• The baseline does unlock calendar keys despite rejected passphrase
  signatures and continues merging events after rejected detached signatures.
  Type/signature downgrades, mixed-card overwrites and missing required cards
  have corresponding characterization tests.
• Controlled-clock fixtures separate key/signature expiry, revocation,
  unknown issuers, malformed signatures and invalid mathematics. They do not
  establish historical Proton-format policy or authorize clock rewinding.

The tests use generated disposable keys and synthetic events only. Tests that
intentionally demonstrate unsafe baseline behavior are labelled Baseline and
KNOWN_GAP; green tests here are not security acceptance. Unsigned formats have
no author-signature assurance. A rejected replacement's local merge target is
protected in the exercised case, but persistent cache/restart safety is untested.

Evidence

The recorded Linux amd64 matrix on 2026-09-14 passed root/nested suites and
focused race checks on Go 1.26.8 and 1.27.1. Each focused run passed 14 top-level
tests plus 35 subtests. Full-root vet failed with the identical two existing
warnings at exports/messages.go:30 on both baseline and contribution.

govulncheck ran, but its JSON exit 0 is not a clean scan. The documentation
separates dependency version exposure from demonstrated defect reachability;
dependency remediation is outside this patch. No live Proton or Thunderbird
acceptance is claimed. The Go files are identical to the executed matrix;
the subsequent documentation revision did not rerun it.

See docs/issue-1-baseline.md and docs/issue-1-results.json for the fixture map,
scope limits, recorded commands, source/toolchain hashes, sanitized results and
per-run fixture hashes.

Proposed gated continuation

I propose keeping one draft PR with separately reviewable commit stages:

1. These baseline fixtures and corrected diagnosis.
2. A policy/acceptance decision record.
3. Dependent no-data-loss safeguards, recovery and visible status.
4. Demonstrated verification fixes and acceptance evidence.

Only stage 1 is prepared. Before behavior changes, could we agree on legitimate
unsigned card roles, historical-expiry policy, whether new unknown-issuer
read-only compatibility should exist at all, and the stale-read/status/recovery
contract? The proposed default is an acceptable retained verified snapshot or
failure; an unknown issuer alone is not evidence of a legitimate historical
author. No new compatibility allowance or strict-verification behavior is
enabled here, and a strict-verification release must wait for the dependent
no-data-loss safeguards.

If you prefer a particular stage split into a separate PR, let's discuss that
before expanding the draft. No production, dependency, public-interface or
state-format changes are included. Recurrence, attendees/invitations, Linux
product support, cache encryption, API migration and release automation remain
outside this stage.