Key-id validity windows for record attestation are declared and unbuilt

[macanderson]

Problem

Profile LC3 says "Key rotation is by key-id validity windows". There is no
validity-window type, no key registry, and no code anywhere that consults one.
PR #114 implements record attestation verification, and it takes a raw public
key from the caller — it has no way to ask whether the key named by key_id was
valid at issued_at, which is the question rotation exists to answer.

The consequence is concrete: a compromised key that has been rotated out still
verifies every attestation it ever produced, and an auditor holding an old
attestation cannot tell "signed while the key was valid" from "signed after it
was revoked".

This is the record-layer sibling of #91 (key distribution and trust roots for
provenance attestation). The two want the same machinery — a key registry with
validity windows — and should probably be designed together rather than twice.

Files

• docs/profiles/context-exchange-provider.md — LC3, LC4, LC5
• contextgraph-types/src/record_attest.rs — verify_record_attestation,
  verify_signed_record_hash; both take public_key: &[u8] and no key id
• contextgraph-types/src/record.rs — RecordAttestation::key_id,
  RecordAttestation::issued_at
• contextgraph-types/src/attest.rs — the frame-layer equivalent, same gap

What is undecided

• Where a key registry lives: in the protocol types, in the host, or out of
  scope for the protocol entirely (a deployment concern, like the auth scheme in
  profile §10).
• Whether a verifier is required to check the window, or whether the protocol
  only defines how a window is expressed and leaves the policy to the host.
• What issued_at is trusted for. It is a self-asserted field inside the signed
  attestation's envelope but not inside the signed message, so an attester can
  restate it freely. Any window check that reads it needs to say what it means.

That last point is the one to settle first; it decides whether the window check
is worth anything.

Done

Either the profile states that validity windows are a deployment concern and
LC3's sentence is corrected to say so, or a window is expressible in the
protocol, a verifier can consult one, and a test shows an attestation issued
outside its key's window failing for that named reason.