feat(auth): record the verified client identity signal on the grant

[tnunamak]

When a client presents an https URL as its client_id, the AS verifies domain control and then throws the result away. The resolver returns a bare RegisteredClient, so nothing on the issued grant records which signal the AS relied on, or when it looked it up. spec-core.md#trust-registry-queries requires both. On main, trust_signal, looked_up_at and framework_uri match zero times in the tree, so anyone auditing a grant after the fact cannot tell whether the client's identity was ever checked.

This stamps the record where the check happens, inside resolveCimdClientForGrant, and reports it under pdpp.trust_signal in introspection. It carries method as well, separating the same-origin branch from the https fetch, so the decision can be reproduced later rather than re-derived.

The record goes in a new nullable grants.trust_signal_json column, not inside grant_json. ResolvedGrantSchema is vendored with additionalProperties: false, so an extra member there would fail every existing grant read. Pre-existing grants read NULL and are not back-filled. No signal was relied on for them, and inventing one would be the opposite of the point.

Staged-batch approval also now forwards the request's base URL into its re-resolution. That drop is pre-existing on main. Without the base URL, CIMD batches fall through to a network self-fetch and fail at approve, so the batch case below cannot be exercised without fixing it.

What the evidence shows

The leg-3 oracle from #56 fails 1 of 3 on main and passes 3/3 here, on SQLite and Postgres 16 — a grant issued through the https-document path reads its signal back through introspection.

cimd-trust-signal-batch-path.test.ts issues a staged batch and asserts each child reports the record through its own token's introspection, so the stamp survives the re-resolution path rather than only the direct one. Both backends.

Two controls were run and reverted after. Dropping g.trust_signal_json from the Postgres join reddens Postgres alone. Restoring the record onto the pending request's client, rather than the resolved child, reddens the batch test at review. Each assertion therefore depends on the change it claims to cover.

For the upgrade path, the column was dropped, a legacy row inserted, and bootstrap re-run on both backends: the column returns, the row survives, and it reads NULL.

Not verified

method: "https_document_fetch" is not exercised end to end. Both harnesses are same-origin by construction, so that branch is covered only by cimd.test.ts with an injected fetchImpl.

Assisted-by: AI