metadata.last_updated has no freshness validator at any threshold

Discovered while remediating review findings on #2599.

## Problem

Skill frontmatter carries `metadata.last_updated`. Nothing verifies it means anything.

`scripts/linting/schemas/skill-frontmatter.schema.json` validates its shape only:

```json
"last_updated": { "type": "string", "pattern": "^\\d{4}-\\d{2}-\\d{2}$" }
```

`Invoke-MsDateFreshnessCheck.ps1` reads only the `ms.date` key, so it never sees this field.

The result is a date that can drift arbitrarily far from reality while passing every check. Before #2599, `powerpoint/SKILL.md` claimed `2026-03-18` at 144 days stale, in a file that had been substantially restructured.

## Related finding worth recording

While investigating this, I confirmed `ms.date` **is** enforced, which corrects an assumption I had made earlier. `Invoke-MsDateFreshnessCheck.ps1` runs in `pr-validation.yml` with `soft-fail: false` and `changed-files-only: true`, and its exclusion list covers only `node_modules`, `.git`, `logs`, `.copilot-tracking`, `plugins`, and `CHANGELOG.md`. It does inspect `.github/skills/**`.

It enforces a 90-day staleness threshold, not an edit-time bump. So a file edited today with a 44-day-old `ms.date` passes, even though `copilot-instructions.md` requires the bump. The mandated rule and the enforced rule are different rules.

## Options

1. Extend `Invoke-MsDateFreshnessCheck.ps1` to read `metadata.last_updated` alongside `ms.date`.
2. Add an edit-time check: if a changed file carries either field and the value did not change in the same diff, fail.
3. Drop the field if it is not going to be maintained.

Option 2 enforces what `copilot-instructions.md` actually mandates and would have caught the #2599 finding. It is also the noisiest.

## Acceptance

- `metadata.last_updated` is either validated or removed.
- If validated, the relationship between the 90-day staleness rule and the edit-time bump rule is documented so the two are not conflated.