Venue re-import dedupe / provenance key (cross-import)

[ibanner56]

Tracked follow-ups deferred from PR A (#452, the Venue entity core). Two related venue concerns for later PRs:

1. Share-bundle venue gathering (PR C — display/export)

buildProgramShareBundle (app/lib/src/export/program_share_bundle.dart) embeds a program but does not gather the program's referenced Venue into CompendiumArchive.venues. A shared program's venueId (schema v13) therefore arrives at the receiver without its venue record, and the core importer safely nulls the dangling reference. Once venueId is populated by the editor UI (PR B) and a venue resolver is wired into the share path, gather the referenced venue here — mirroring the dance/choreographer gathering, and applying the same privacy sanitization to venue contact fields.

2. Venue re-import dedupe / provenance key

The community/backup import path (CompendiumArchiveImporter) mints a fresh venue id for every bundled venue (deliberately, so an untrusted bundle can never clobber an existing venue). Venues carry no provenance/dedupe key across imports, so re-importing the same bundle inserts duplicate venue records and orphans the previously-imported ones (the deduped program is repointed to the newly-minted venue). This is accepted for PR A as consistent with the additive-import model, but should be resolved with a venue provenance/dedupe primitive so a re-imported bundle matches existing venues instead of duplicating them.

Note: within-bundle duplicate venue ids are already collapsed in PR A; this issue tracks only the cross-import case.

Refs: PR #452.

[ibanner56]

Split: Item 1 (share-bundle venue gathering) is now shovel-ready — its dependencies (PR B #492, PR C #502) have merged — and has been carved out to #515 with a full implementation spec (incl. the maintainer's opt-in contact-PII consent dialog ruling).

This issue now tracks only Item 2 — the cross-import venue dedupe / provenance key, which still needs a design decision (the dedupe primitive is security-sensitive: fresh ids are minted today specifically so an untrusted bundle can't clobber an existing venue, so any provenance/match key must not reintroduce that risk). Not yet shovel-ready; no work kicked off.

[ibanner56]

Shovel-ready spec — cross-import venue dedupe / provenance key

Design resolved with the maintainer. Fixes the tracked limitation where re-importing a bundle mints a fresh venue every time, duplicating venue records (see compendium_archive_import.dart:341-352 + TODO(#456) at :346).

Strategy: content fingerprint, never-overwrite, strong-key-only

No schema change, no migration — venues get no stored provenance column. Matching is by a computed normalized fingerprint; on a match the incoming venue is dropped and the program is repointed to the existing venue, never overwriting the existing record. This deliberately differs from the program/dance (source, externalId) update-in-place dedupe: fresh-mint exists precisely so an untrusted bundle can't mutate an existing venue, and this preserves that guarantee.

Fingerprint (new pure core helper, e.g. venueFingerprint(Venue) -> String?)

• Key fields: name + city + stateProv + address1, each normalized: trim → lowercase (casefold) → collapse internal whitespace. Join with an unambiguous separator.
• Strong-key threshold: return a key only when name is non-empty AND (address1 OR city) is non-empty. Otherwise return null (weak key → never dedupe).
• Excludes the redactable contact fields (contact1/2*), notes, price, schedule, website, etc. — critical, because Share-bundle venue gathering with contact-PII redaction + opt-in consent dialog #515 strips contact PII by default, so a shared venue must fingerprint-match a local one using only fields that always travel.

Import behavior (additive CompendiumArchiveImporter path only)

Applies where venues are fresh-minted today (commit, the loop at :353-362) — covers community share bundles (post-#515) and additive full-archive imports. Replace-mode backup restore is out of scope (separate wipe-and-restore path; preserves ids; must not dedupe).

Per bundled venue, in first-seen order:

1. Within-bundle collapse (unchanged): a repeated original id still collapses to one minted venue (last-seen content), as today.
2. Compute venueFingerprint(incoming).
   • Weak key (null) → fresh-mint + insert (today's behavior).
   • Strong key → look up existing venues by fingerprint:
     • Exactly one existing match → dedupe: map original venue id → existing venue id; do not upsert/insert; do not modify the existing venue; do not add it to insertedVenueIds.
     • No match → fresh-mint + insert.
     • >1 existing match (ambiguous) → treat as no match: fresh-mint (never guess which to merge into).
   • Also fold this import's just-minted venues into the fingerprint index so two fingerprint-equal venues within one bundle collapse to one (consistent with the within-bundle id collapse).
3. venueIdByOriginalId (already used by buildArchivePrograms to remap program.venueId) absorbs both minted and deduped-to-existing ids, so programs resolve to the right venue with no further change.

Existing-venue lookup

• Add a VenueRepository method to build a fingerprint → venueId index from existing venues (compute venueFingerprint over listAll, drop weak/null keys, and record fingerprints that map to >1 id as ambiguous so step 2 can fresh-mint on them). Venue counts are small; a single load is fine (avoid an N+1 of per-venue queries). Build it once per commit before the venue loop.

Undo / safety invariants

• insertedVenueIds MUST continue to contain only newly-minted venues. A deduped (matched) venue is a pre-existing record, so it stays out of insertedVenueIds and undo never deletes a venue the user already had — only this import's true inserts are reverted. Add/keep a test asserting this.
• Never-overwrite: a matched existing venue's fields are never touched by the import.

Sequencing

• Not blocked by Share-bundle venue gathering with contact-PII redaction + opt-in consent dialog #515: additive full-archive re-import already embeds venues today, so the duplicate bug is reproducible and testable via that path now. Share-bundle venue gathering with contact-PII redaction + opt-in consent dialog #515 (share-bundle venue gathering) is what makes the community-share re-import case exercise this too. Related, not blocking.

Acceptance criteria

• venueFingerprint: normalization (trim/lowercase/collapse-ws) over name+city+stateProv+address1; returns null unless name AND (address1 OR city) present; ignores contact/notes/price/etc.
• Re-importing the same additive bundle a second time inserts 0 new venues and repoints programs to the existing venue (regression for the Venue re-import dedupe / provenance key (cross-import) #456 duplicate).
• Never-overwrite: importing a same-fingerprint venue with different contact/address2/notes leaves the existing venue's fields unchanged.
• Weak key (name-only venue) → fresh-mint (no false merge).
• Ambiguous (incoming fingerprint matches 2 existing) → fresh-mint, no merge.
• Within-bundle: two fingerprint-equal venues in one bundle collapse to one inserted venue.
• undo after a deduped import deletes only newly-minted venues and never a pre-existing matched venue.
• Replace-mode restore path is unchanged (no dedupe).
• Core stays Flutter-free; no schema/migration change.

Refs: #515 (share-bundle venue gathering, related), PR #452 (Venue core), compendium_archive_import.dart, dedupe.dart, provenance.dart (program/dance precedent — intentionally NOT copied for the overwrite behavior).