fix(schema): re-sync the two revocation mirrors as well

The parity job guards three published schemas as a set, and all three had
drifted. Cleaning only trace-v0.2.json left the job red for the other two,
which is both a broken check and a half-fix: the revocation schemas are
published at the same $id pattern and fetched by the same verifiers.

The drift is three "maximum": 9007199254740991 constraints, the safe-integer
bounds upstream added alongside the ones in trace-v0.2.json. Until now the
published copies accepted revocation records carrying integers no JSON parser
round-trips reliably.

No dashes in either file, which is why the original sweep did not reach them.
Re-synced from upstream rather than hand-patched, for the reason in the
previous commit: parity is a byte comparison and a partially-updated mirror is
not a mirror. Both $id values verified unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014NL8o3PXq6kfs2SdmBv6ak

Author: imran-siddique

schema/trace-revocation-bundle-v1.json

@@ -27,11 +27,13 @@
     "issued_at": {
       "type": "integer",
       "minimum": 1700000000,
+      "maximum": 9007199254740991,
       "description": "When the bundle was assembled, Unix epoch seconds."
     },
     "valid_until": {
       "type": "integer",
       "minimum": 1700000000,
+      "maximum": 9007199254740991,
       "description": "The horizon this bundle may be relied on to. Past it, a verifier reports the record as unverified for revocation rather than verified: an expired bundle is not evidence a key is still trusted, and spec section 3.2.3 forbids reporting it as an affirming appraisal."
     },
     "statements": {

schema/trace-revocation-v1.json

@@ -51,6 +51,7 @@
     "revoked_at": {
       "type": "integer",
       "minimum": 1700000000,
+      "maximum": 9007199254740991,
       "description": "When the revocation was issued, Unix epoch seconds. Informational only. It is deliberately NOT the boundary: see the description of this schema."
     },
     "revocation_key_id": {