MCP: reject pre-provenance refresh families at refresh time (lazy migration, defense in depth)

## Summary

Reject pre-provenance MCP refresh families at refresh time, as defense in depth.

A refresh family minted before the plugin's provenance model carries an upstream claim as its token `sub`. That `sub` reaches the application as `request.mcp.sub` and is never resolved against `hdb_user` (the `/mcp` route runs outside core auth and sets no `request.user`), so it is an application-facing identifier rather than a Harper role — but a family that predates the model is still worth retiring on principle.

## Proposal

Stamp families minted by the current version, and have the refresh path reject an unstamped (pre-provenance) family with `invalid_grant`, forcing the client to re-authorize into a stamped family. This is a per-family, lazy migration: no startup sweep, no marker, nothing to get wrong on restart, and it converges naturally across a rolling upgrade because every node's refresh path enforces it. Exposure of an unstamped family is bounded by the access-token lifetime, since a family cannot keep working without refreshing.

## Context

An eager startup revocation sweep was removed because its failure mode (a re-run revoking every current family) was worse than the app-facing risk it guarded. Lazy stamp-reject is the restart-safe shape if the defense in depth is wanted.

Start at the MCP refresh path and the /mcp route, tracing how the refresh family reaches request.mcp.sub without request.user. Confirm where current-version families can be stamped, then verify that an unstamped family is rejected with invalid_grant while stamped families continue to refresh and clients can re-authorize.

Written by the indexing model from the issue text.