Release notes — AdvisoryAI unified search resolves entity aliases (sprint SPRINT_20260916_001, RFC-13)

What changed

Unified search now resolves an identifier to the entity it was indexed under. The resolution table advisoryai.entity_alias had readers on every search query and no writer, so every lookup returned nothing. The unified search indexer now writes it.

• Search by an alias. A query that matches a registered alias returns an entity_alias refinement naming the canonical entity key, for example an image content digest (sha256:…) resolving to image:<reference>, or an image reference resolving to the scan that names it.
• Entity cards. A result keyed by an alias is grouped under the canonical entity’s card, and the card lists the entity’s aliases as connections.
• Identity families filled today. The scan adapter’s declared image reference and the graph adapter’s image content digest. The writer takes advisory aliases (for example a GHSA identifier on a CVE) from any adapter that declares them. No current upstream payload carries such a pair, so none are filled yet.

Operator-visible behavior

• Rows appear after the next unified index pass or rebuild. No action is needed, and no configuration key was added.
• POST /v1/search/index/rebuild rebuilds the alias table together with the adapter documents. An emptied table is restored by the next pass.
• Only tenant-neutral index entries (tenant absent or global) contribute aliases. The table has no tenant column, so a tenant-scoped identity is never registered.
• Retention class: derived-rebuildable (forward migration 007_advisoryai_entity_alias_retention.sql, comment-only; it applies on startup).

Verification

EntityAliasIndexingTests runs the indexer, the alias service, unified search and the card assembler against the migrated schema. See the AdvisoryAI dossier section “Cross-identifier alias resolution” (docs/modules/advisory-ai/architecture.md).