Proposal: Make the TD Identity artifact optional

## Original Title: Make the TD Identity artifact optional

## Summary

Remove the **TD Identity** artifact (`isvsvn → (tcb_date, tcb_status)`)
entirely and drive the MigTD portion of migration policy from the ISV
**SVN alone**. MigTD's runtime identity lookup becomes a single step:
`SERVTD_INFO_HASH → isvsvn` (TCB Mapping). The SVN→date/status
correspondence moves out of the runtime trust surface into
**policy-authoring time**.

## Motivation

* **A MigTD TCB date is redundant with its SVN.** A date is only more
expressive than an SVN when it is *globally comparable* across components —
that is why platform TCB uses dates ("everything before 2024-01-01 is
stale" holds across the TDX module, microcode, etc.). MigTD's release
cadence is **independent** of those Intel components, so a MigTD `tcb_date`
carries no cross-component freshness meaning; it degenerates to a
per-release monotonic ordinal — which the SVN already is, only
non-canonical. The date is therefore pure redundancy.
* **SVN already is the security ordinal.** Any "modern enough" judgment a
date expresses can be expressed directly as an SVN bar
(`migtdIdentity.isvsvn >= N`, absolute; or `>= self` / `>= init`,
relative). The SVN→date correspondence is not lost: it moves to
policy-authoring time — an operator who used to write
`tcbDate >= 2026-04-03` now writes `isvsvn >= N`, where `N` is the SVN cut
around that date, chosen once, offline.
* **Simplification.** Deletes a second signed CFV artifact, its signature /
verification path, and an SVN→date table from the runtime trust surface —
leaving the MigTD identity lookup as one hash→SVN step.

### Assumption

This proposal rests on the premise that **MigTD SVN is bumped only for
security-relevant changes** (the same monotonic, security-bumps-only
discipline as the TDX-Module SVN): a new SVN means a security-relevant change;
perf/bug-fix releases do not bump it. If that release discipline does not
hold, an SVN bar is a weaker signal than a date and the argument above does
not stand — so the discipline should be treated as a requirement of this
design, not an assumption to be revisited later.

## Security: no rollback regression

Removing TD Identity does **not** weaken rollback defense — the date/status it
carried was never what resisted rollback. The minimum SVN bar in the policy,
measured into RTMR2, prevents substituting a MigTD whose hash maps to a lower
SVN: an attacker cannot lower the bar without changing the local MigTD's own
measurement (so its own peer would then fail to resolve it), and cannot change
the SVN a hash maps to without forging the issuer signature.

Scope note: this covers substituting a *lower-SVN MigTD*. It does **not**
address rollback of the signed TCB Mapping itself (presenting an old signed
mapping) — that is #908's concern (detached, unmeasured mapping), orthogonal
to removing TD Identity.

----

## Update

Adopting the feedback: instead of removing TD Identity, it becomes an
**optional**, **simplified** artifact.

* **SVN is the default.** Policy authored with SVN bars
(`migtdIdentity.isvsvn`) needs no TD Identity at all — MigTD's identity
lookup is a single `SERVTD_INFO_HASH → isvsvn` step.
* **TD Identity is an optional add-on.** When shipped, it lets migration
policy additionally use `tcbDate` / `tcbStatus` bars, giving operators the
freedom to choose date/status-based policy.
* **JSON-only.** There is no CoRIM form of TD Identity (the tenant / remote
attestation flow never consumes it).

The motivation, assumption, and rollback analysis in the original description
still hold for the SVN-default case; this update only changes "remove" to
"make optional" and simplifies the format.

## Simplified TD Identity format

Because the TCB Mapping now matches by `SERVTD_INFO_HASH` (#908), TD Identity
no longer needs to describe the MigTD's `TDINFO_STRUCT`. The former register
descriptors (`xfam`, `attributes`, `mrConfigId`, `mrOwner`, `mrOwnerConfig`,
MRTD/RTMRs), the original-TcbMapping-specific `mrsigner` / `isvProdId`, and `tcbEvaluationNumber`
are **dropped**, leaving an envelope + an `isvsvn → (tcbDate, tcbStatus)` table:

```json
{
"id": "A0998F0F-B2F3-4872-8138-FBC2B853E8C6",
"version": 1,
"issueDate": "2025-01-01T00:00:00Z",
"nextUpdate": "2026-01-01T00:00:00Z",
"tcbLevels": [
{ "tcb": { "isvsvn": 1 }, "tcbDate": "2024-01-01T00:00:00Z", "tcbStatus": "UpToDate" }
]
}
```

Signed as `{ "tdIdentity": { … }, "signature": "" }`, embedded as
optional `servtdIdentity` + `servtdIdentityIssuerChain` in `servtdCollateral`.

## Behavior

* **When present:** policy may use `migtdIdentity.tcbDate` /
`tcbStatusAccepted` bars, resolved via `hash → SVN` (TCB Mapping) then
`SVN → (date, status)` (TD Identity).
* **When absent (SVN-only):** SVN bars (`migtdIdentity.isvsvn`) work as
before; a `tcbDate` / `tcbStatus` bar with no TD Identity present is a
policy-authoring error and **fails closed**.

Start by locating the servtdCollateral and migration-policy handling, then trace how TCB Mapping and TD Identity artifacts are parsed, verified, and used for policy bars. Compare the present, absent, and invalid-usage cases described in the issue; done means SVN-only policies work, optional JSON TD Identity supports date/status bars, and date/status bars without the artifact fail closed.

Written by the indexing model from the issue text.