#3863 Registry rescore: secret-safe-docs passes a secret README line on versions whose stored metadata predates the sensitive flag (follow-up to #3783)

Follow-up to #3783 (swamp-club PR 1405). Found in that PR's review and not fixed there, because the fix is a design choice.

What happens

The registry's secret-safe-docs detector checks a declared argument by name only when the metadata does not mark it sensitive. When the metadata does mark it sensitive, the schema decides. The sensitive flag only exists in content metadata stored from #3783 on.

Content metadata stored before #3783 has no sensitive field at all. Neither does metadata pushed by a CLI that doesn't send it, because confirm-push.ts prefers client metadata over server extraction. For those versions a missing flag means "unknown", but the scan treats it as "not sensitive".

Repro

1. Take a version published before #3783 that declares apiToken: z.string().meta({ sensitive: true }) and whose README contains --global-arg apiToken=abc123.
2. The owner clicks Rescore.

Result: apiToken is declared and not marked sensitive in the stored metadata, so the README line passes and the version earns secret-safe-docs. Expected: the point is withheld, as swamp extension quality on the same source does.

Impact

This breaks the CLI/registry parity promise in AGENTS.md, but only for rescores of versions whose metadata predates #3783. New pushes from a current CLI carry the flag.

Fix options (decide one)

• Record a metadata version, and fall back to the name check when the version predates sensitive.
• Re-extract the argument schemas from the archive on the server when scoring, instead of trusting stored metadata.

Acceptance

• A unit test with pre-#3783 metadata and the repro README withholds the point on rescore.
• Rescoring a version stored with the flag behaves as it does today.