Emit the Content Seal as its own signal on standalone-AI-tag files

The strength router already bets that a file whose only provenance is
the standalone AI digital-source tag is Meta Muse output (C2PA issuers
win first), and Muse stamps every output with the invisible Content
Seal. identify now surfaces that same bet as evidence: the additive
content_seal signal (medium confidence - an attribution, not a decode,
since no public decoder exists) plus the watermark string, emitted on
exactly the standalone_iptc condition that routes the cohort. Clients
select pixel removal from the signal list instead of parsing caveats,
the way InvisMark is additive over soft_binding. The API's invisible
gate already runs on ai_from_metadata, so all/invisible behavior is
unchanged; has_invisible_target needs no edit.

docs/supported-signals.md

@@ -165,7 +165,12 @@ This project has no local Content Seal decoder. Meta Model API outputs and
 Meta CDN copies carry an XMP `iptcExt:DigitalSourceType =
 trainedAlgorithmicMedia` companion tag, which `identify` reports through the
 existing Made-with-AI path; that IPTC code is a standard, not a Meta-exclusive
-signal, so it cannot key a strength cohort the way the C2PA issuer does. The
+signal, so it cannot key a strength cohort the way the C2PA issuer does. Since
+0.33.0 a standalone AI digital-source tag (no C2PA manifest) additionally emits
+the additive `content_seal` signal - the strength router's Meta bet as evidence,
+medium confidence, with the same caveat - so clients select pixel removal from
+the signal list exactly the way InvisMark is additive over `soft_binding`. It
+is an attribution, never a decode. The
 external oracle is `https://meta.ai/identification`: anonymous, no login,
 accepts image, video, and audio, enforces an unspecified daily identification
 limit, and answers with model attribution (`Muse Image 1 - Meta`) plus a