Camera-roll import / photo retrace

Summary

"Import from Camera Roll" (in-app UI: "Retrace my steps") lets a user backfill their Scout collection from photos they already have, instead of only unlocking patches by physically carrying the phone there. The app reads GPS and timestamp metadata off the user's photo library (or one album, or a hand-picked selection), sends the coordinates to the backend in batches, gets back which patches' boundaries contain each point, and lets the user pick which of the found patches to add to their collection. The patch's "collected" date is set to the photo's own creation date, not the moment of import. Patches earned this way are explicitly tagged source: 'import' and are excluded from the achievement system — only in-person GPS unlocks count there. No image ever leaves the device; only latitude/longitude and a timestamp are sent to the backend.

Status (shipped / beta-badged / flagged off)

Shipped, fully live, no feature flag. There is no photo_import-style entry in the feature-flag registries (mobile/src/config/feature-flags.ts, backend/src/app-config/app-config-schema.ts) and openSource/usePhotoImport run unconditionally. Unlike sibling drawer items ("The Album", "My Patches" grouping, "Day Trip", "Road Trip"), the drawer's "Import from Camera Roll" row carries no trailing: betaBadge — it is not marked beta (mobile/src/components/navigation/drawerSections.ts:246-251). The only gate is isVisible: (ctx) => ctx.hasSession, and guests get a session, so it is visible to essentially every user, signed-in or not.

User-facing surfaces (screens, routes, deep links, entry points)

• Drawer entry: Drawer → YOU → "Import from Camera Roll" (mobile/src/components/navigation/drawerSections.ts:246-251), href: '/import-modal'.
• Deep link: scout://import-modal, registered in mobile/src/dev/deepLinkRoutes.ts:105 (category "Patches").
• Screen: mobile/app/import-modal.tsx — a single pushed full screen (the filename is historical; a comment at the top notes it used to be a page-sheet before the flow grew multiple "beats"). It renders different content per usePhotoImport state:
  • idle / no_matches → RetraceInvite (.../retrace/RetraceInvite.tsx) — the entry card with a "Retrace my steps" primary CTA and a "Choose what to scan" secondary link.
  • choosing_source → ImportSourceSheet — pick "Entire library" / "An album" / "Specific photos".
  • choosing_album → AlbumPicker — a two-up grid of device albums, richest first.
  • requesting_permission / selecting → a brass spinner (ScanDial).
  • permission_denied / limited_access / error → dedicated cards, each with a "Pick photos instead" escape hatch.
  • processing (phase tracing), confirming (phase claiming), saving / success (phase finishing) → all three render RetraceSurface, one continuous surface that morphs from a live scan animation into a claim grid into a gold reward stamp.
• No other screen embeds this flow — it is reached only via the drawer / deep link, not from a patch detail page or the map.

How it works (end-to-end mechanism)

1. Source selection. usePhotoImport.runImport(source) (mobile/src/hooks/usePhotoImport.ts:216) drives everything from here on; scanAllPhotos/scanAlbum/selectPhotos are thin wrappers that pick a ImportSource ({kind:'library'}, {kind:'album', albumId, title}, or {kind:'picked'}).
2. Acquisition (mobile/src/hooks/photoImportSources.ts, openSource):
   • library/album: requests expo-media-library permission on demand (tied to the user's tap, not screen mount), then pages through MediaLibrary.getAssetsAsync in batches of 100 (BATCH_SIZE), reading up to 15 assets concurrently per batch (READ_CONCURRENCY).
   • picked: opens expo-image-picker's native multi-select (launchImageLibraryAsync with exif: true), which needs no library permission grant at all.
3. Per-photo GPS read. For library/album, each asset's location comes from expo-media-library/build/next's Asset(nextAssetRef(id)).getLocation() — deliberately not MediaLibrary.getAssetInfoAsync. A code comment (photoImportSources.ts:128-137) documents the measured trap: on a 131-photo simulator library, getAssetInfoAsync took 174ms/photo (its iOS path resolves a PHContentEditingInput and decodes the file off disk to build a full EXIF dictionary), ran on the main thread, and dragged the UI to ~4fps for the whole scan (27.1s total). getLocation() reads only PHAsset.location (Android: the EXIF header via ExifInterface), measured at 1.3ms/photo with identical results (0.30s total for the same 131 photos). mediaAssetRef.nextAssetRef() (mobile/src/utils/mediaAssetRef.ts) translates the legacy asset id into the next API's id shape (ph:// on iOS, a rebuilt content://media/external/images/media/<id> URI on Android).
   • For picked photos, GPS instead comes from the EXIF dict ImagePicker already returns (extractGpsCoordinates, mobile/src/lib/exif.ts), applying the N/S/E/W sign to the raw magnitudes.
   • A read failure is tallied separately from "no GPS" (LocationRead's ok: false branch) so a systematic failure surfaces in logs rather than silently reading as "none of your photos have location."
4. Matching, page by page. As each page of GPS-bearing photos comes back, usePhotoImport chunks it to 100 (MATCH_CHUNK, since the batch endpoint caps at 100 locations — see below) and calls matchPhotosToPatches (mobile/src/utils/unified-photo-matching.ts:336), which calls POST /api/location/check-batch (mobile/src/utils/unified-photo-matching.ts:140, backend at backend/src/location/location.controller.ts:39 / backend/src/location/location.service.ts:89). If the backend call throws, matching falls back to a client-side Haversine centroid-plus-radius check (matchViaClientFallback) — which cannot see polygon boundaries at all, only patches with a plain lat/lng, so an offline/degraded import silently misses every polygon-backed (city, state, NPS, OSM) patch until a later backend-connected pass runs.
   • A previous page's match is awaited before the next page's match starts (keeps memory/accumulator updates serial), while the acquisition generator is already fetching/reading the next page in parallel — so disk reads and the network round-trip overlap.
5. Server-side containment (LocationService.checkBatch, backend/src/location/location.service.ts:89-203) runs two SQL queries per batch:
   • Point match: for patches with neither a protectedAreaId nor a geofenceId (a bare lat/lng pin), ST_DWithin within photoMatchRadiusMeters (AppConfig key, default 150m — deliberately larger than live-tracking tolerance because photo GPS is less accurate).
   • Polygon match: ST_Contains against protected_areas.geom UNION geofences.geom — plain containment, no buffer. A comment (location.service.ts:144-159) documents that this replaced an earlier blanket photoPolygonBufferMeters (10m) applied to every polygon, which let a whole stadium be "earned" from the pavement outside it; any tolerance a subject needs (a statue, a monument) is now baked into the geometry itself (geofences.source = 'osm_buffered'), not into the import path. This makes camera-roll import agree with the live-tracking unlock rule (checkPolygons) for every polygon-backed patch — the one documented exception is a PatchPhoto near-miss buffer used elsewhere for photo check-in verification, not this batch path; see location.geometry.db.spec.ts's own comments for that history.
   • Because containment is queried directly (not per-photo iteration), a single photo inside nested boundaries (e.g. a zoo inside a city park inside a city inside a state) returns every containing patch as an independent direct match — there is no separate "cascade" step; that logic was deleted (unified-photo-matching.ts:257-266) when city/state patches got real boundary polygons.
6. Accumulation. createMatchAccumulator() (mobile/src/hooks/photoImportMatching.ts) dedupes matches by patch id as pages stream in, keeping the earliest photo date per patch (so if the same place appears in five photos, the earliest one's date is what gets recorded), while preserving first-seen order for the "recently found" strip shown during the scan.
7. Visit photos (device-local, not the community gallery). Every matched still photo (not video) that has a durable MediaLibrary asset id is kept as a (patchId, assetId, takenAt) pair (visitPhotoPairsFrom, mobile/src/hooks/visitPhotoCapture.ts:40) and committed to the Zustand store's visitPhotos map (addVisitPhotos → mobile/src/domain/visitPhotos.ts:37, deduped by (patchId, assetId)) as soon as the scan finishes — independent of which patches the user later chooses to collect. This is what populates a patch's "My Visit" photo carousel. These are private on-device references (never uploaded as image bytes here); they are distinct from the public PatchPhoto gallery rows (see "What this feature does NOT do").
8. Confirm. The user reviews the claim grid (already-collected patches shown disabled but not re-collectable) and taps "Add N to my guide" → confirmImport() → store.collectPatchBatch() (mobile/src/domain/store.ts:1639), which enqueues a PendingPatch per newly-selected patch with collectedAt: <the photo's creationTime> and source: 'import', then relies on the ordinary sync push (POST /api/sync/push, JWT-guarded) to write it to UserPatch on the server. Anything already in userPatches is silently skipped (no duplicate row, no re-collect).
9. Analytics-only reporting of misses. Photos that had GPS but matched no patch (capped at 500, MAX_POTENTIAL_MATCHES) are POSTed to POST /api/potential-matches (no auth guard; carries only lat/lng, a null place name, and the photo's date) so Scout can see where users go that aren't covered by a patch yet. This is the only place is genuinely "leaves the device" beyond the check-batch coordinates themselves — still never an image.

Data model (Prisma models and key fields)

• UserPatch (backend/prisma/schema.prisma:785-808) — the collected badge. source: String @default("unknown") records how it was earned; 'gps' is the only value that counts for achievements, 'import' (this feature) and 'unknown' (pre-column rows) do not (backend/src/achievements/feature-context.ts:12 — IN_PERSON_SOURCE = 'gps'). collectedAt: DateTime is set from the photo's own creation time, not now() — see step 8 above.
• PotentialMatch (schema.prisma:1055-1070) — the "no patch matched this location" analytics row: userId?, deviceId?, latitude, longitude, placeName? (always null from this path — see usePhotoImport.ts:322-327), photoDate?.
• Patch.protectedAreaId / Patch.geofenceId — which polygon table (if any) a patch's boundary lives in; checkBatch unions both, and a patch with neither falls back to the point-radius path.
• PatchPhoto (schema.prisma:405-431) is the public community gallery row and is not written by this feature (see "does NOT do"); it is a separate, unrelated upload path.
• Visit photos (VisitPhotoRef / VisitPhotosMap, mobile/src/domain/visitPhotos.ts) are not a backend table — they live only in the Zustand store on-device (persisted via MMKV), keyed by patch id.

API surface (endpoints, auth requirements)

There is no dedicated "import" backend endpoint; the mechanism reuses the generic location-matching and sync infrastructure.

Key files (annotated)

• mobile/app/import-modal.tsx — screen orchestrator, state→UI mapping, back navigation, post-success sync trigger. Split into the house view-model pattern: ImportModalScreenViewModelImpl owns every hook (the usePhotoImport machine, the no-matches alert, the post-success sync and auto-dismiss, Linking.openSettings), and ImportModalScreenLayout is a pure layout that draws the view model. Two pure helpers are exported so the screen-mock gallery derives the same chrome the screen does rather than asserting it by hand: importModalSurface(state) maps an ImportState onto the ImportModalSurface discriminant (invite / choosing-source / choosing-album / waiting + its dial label / permission-denied / limited-access / retracing + its RetracePhase / error), and importModalShowBack(state) is the back-chevron rule (hidden on saving and success). The view model carries the scan as DATA — progress (scanned / total / matchesFound / recentMatches), sourceLabel, the per-match matches with their alreadyCollected flag, selectedPatchIds, and the reward counts — never a rendered node.
• mobile/src/hooks/usePhotoImport.ts — the state machine: acquire → page → match → accumulate → confirm → save. MATCH_CHUNK = 100 (line ~140) is deliberately decoupled from the media page size (100) but coincidentally equal to the batch endpoint's cap.
• mobile/src/hooks/photoImportSources.ts — where photos come from (openSource); the getAssetInfoAsync performance trap is documented at lines 128-149; BATCH_SIZE/READ_CONCURRENCY tuning at lines 74-75.
• mobile/src/hooks/photoImportMatching.ts — MatchResult flattening and the dedupe accumulator (earliest-date-wins).
• mobile/src/hooks/visitPhotoCapture.ts — turns a match result into device-local visit-photo pairs; the video/no-asset-id exclusion rule lives here (lines 21-39).
• mobile/src/utils/unified-photo-matching.ts — the shared matcher used by both camera-roll import and single-photo check-in; backend-first with a polygon-blind client fallback (lines 105-256); per-photo bucketing into new/already-collected (lines 297-314).
• mobile/src/utils/mediaAssetRef.ts — the next-API id translation (iOS ph://…, Android reconstructed content://…).
• mobile/src/lib/exif.ts — shared EXIF GPS parser (used by both the picked path here and the separate upload picker).
• mobile/src/domain/visitPhotos.ts — pure reducer for the on-device patch→photo map (add/remove/dedupe).
• mobile/src/domain/store.ts:1639 (collectPatchBatch) — writes the source: 'import' pending patches; comment at line ~1671 states plainly these "earn no achievements."
• mobile/src/components/import/retrace/* — the presentation layer: RetraceInvite (entry card), ImportSourceSheet (source picker), AlbumPicker (album grid), RetraceSurface (the combined scan/claim/reward surface), RetraceMap + retracePath.ts (the animated route drawing — see below), RetracePatchGrid (TraceCell/ClaimCell).
• backend/src/location/location.service.ts — checkPolygons (live tracking, hard containment) vs checkBatch (import: point-radius for pin-only patches, hard containment for polygon patches).
• backend/src/location/dto/location.dto.ts — CheckBatchDto (100-location cap), LocationInput.
• backend/src/potential-matches/potential-matches.service.ts — stores unmatched-photo analytics rows.
• backend/src/app-config/app-config-schema.ts:51-67 — photoMatchRadiusMeters (used, default 150m) and photoPolygonBufferMeters (still present in the admin-editable schema but not read anywhere in current location.service.ts — see Open Questions).

Configuration and flags

• No feature flag gates this feature (see Status).
• photoMatchRadiusMeters (AppConfig, admin-editable, default 150m, range 50–500m) — the only tunable that affects matching: it sets the point- match radius for patches that have neither a geofence nor a protected-area polygon. Mobile has its own local fallback default of 150m (mobile/src/domain/app-config/types.ts:30, DEFAULT_APP_CONFIG) used if the app-config fetch hasn't landed yet, and also as the client-fallback Haversine radius when the backend call fails outright.
• MAX_POTENTIAL_MATCHES = 500 (mobile, hardcoded) — caps how many unmatched-photo rows one scan will upload.
• BATCH_SIZE = 100 / READ_CONCURRENCY = 15 (mobile, hardcoded, tuning constants for the native photo sweep, not user- or server-configurable).

Edge cases and known limits

• No GPS on any scanned photo: if the whole sweep finds zero GPS-bearing photos and the source was not limited access, the user sees "Scanned N photos but none had location data. Please enable GPS/Location when taking photos." (usePhotoImport.ts:380-382) and lands back in an error state.
• iOS limited-library selection: MediaLibrary.requestPermissionsAsync() reports accessPrivileges === 'limited'. If the totalCount visible is 0, the flow shows a distinct "limited_access" card rather than implying the library has no GPS photos (photoImportSources.ts:346-350); if photos are visible but zero of them have GPS, the same "limited_access" branch fires instead of the generic no-GPS error, because "the odds a hand-picked subset happens to include GPS photos are low" (usePhotoImport.ts:372-378). expandPhotoAccess() calls MediaLibrary.presentPermissionsPickerAsync(['photo']) to widen access (re-opens the system picker on Android 14+/limited-library manager on iOS); if that call itself throws, it falls back to Linking.openSettings().
• Android ≤12 (API ≤32) breakage (regression-guarded, not currently live): a Regression test (mobile/src/config/__tests__/androidMediaPermissions.test.ts) pins that WRITE_EXTERNAL_STORAGE and every permission expo-media-library's config plugin requests must not be listed in android.blockedPermissions. If it were blocked, MediaLibraryModule.hasReadPermissions()'s pre-Tiramisu branch would demand READ_EXTERNAL_STORAGE + WRITE_EXTERNAL_STORAGE together with no manifest check, so the read gate would fail forever; the failure would be silent up front (requestPermissionsAsync() still resolves granted, since it adapts to what the manifest actually declares) and only surface later as getAssetsAsync throwing ERR_PERMISSIONS. API 33+ (READ_MEDIA_IMAGES) is unaffected either way.
• Video handling: on iOS, videos are swept alongside photos (sweepMediaTypes() includes MediaLibrary.MediaType.video) because PHAsset.location is populated for videos the same cheap way as stills, so a video's GPS can unlock a patch. On Android, videos are excluded from the sweep entirely — ExifInterface (the fast path used there) has no MP4/MOV parser, a video's coordinates live in the QuickTime udta atom reachable only via MediaMetadataRetriever (which expo-media-library doesn't expose), and nextAssetRef() only builds an images content:// URI. On both platforms, a matched video is used to unlock the patch but is never kept as a "My Visit" photo reference — visitPhotoPairsFrom drops any kind === 'video' photo, because that list feeds the cloud-album upload path, which is built for still images only.
• Photos with no location: silently skipped during the sweep (not reported as errors; only a genuine read failure is tallied and logged separately — see LocationRead).
• Backend call failure: falls back to client-side Haversine matching, which is polygon-blind (centroid + radius only) — city/state/NPS/OSM polygon-backed patches will not be found until a backend-connected re-scan.
• Cancel mid-scan: reset()/unmount flips a ScanToken.aborted flag checked at every page boundary and every READ_CONCURRENCY chunk inside a page; partial results are discarded, not surfaced.
• Repeat scans / dedup: matching a patch that's already in the user's collection buckets it into alreadyCollectedMatches (shown disabled in the claim grid, not re-collectable, not re-synced) but the photo is still attached to visit photos. Visit-photo refs dedupe by (patchId, assetId) (addVisitPhotoRefs), so rescanning the same library twice does not duplicate "My Visit" entries.
• The animated map is decorative, not geographic: RetraceMap/retracePath.ts draws one fixed, hand-authored SVG route (ROUTE_D, 320×190 design space) with a reticle and 7 fixed "pin" positions that "bloom" as a subset — none of this reflects the user's actual photo locations. It is driven purely by the real scan's scanned/total fraction (via a shared value animated with withTiming), so its pacing is real but its geography is not.
• no_matches is invisible to anything but a person watching the screen. It renders the same RetraceInvite as idle — the only thing that marks it is a native Alert.alert("No patches matched", …) fired from an effect, which is not part of the view tree. So a screenshot, a screen test and the screen-mock gallery cannot tell no_matches from idle, and the gallery deliberately does not register a state for it.
• The user is never told how many photos matched nothing. Photos that had GPS but hit no patch are counted only for POST /api/potential-matches; the claim header reports found patches and the scan bar reports photos read, so the miss count only ever exists as the arithmetic gap between them (e.g. "1,864 of 4,182" read, "12 patches found"). There is no "N photos matched nothing" line anywhere in the flow.
• The scan radius silently falls back when app-config has not landed. usePhotoImport reads photoMatchRadiusMeters via useQuery(appConfigQuery()) and drops both isLoading and error (usePhotoImport.ts:149-151), defaulting to DEFAULT_APP_CONFIG .photoMatchRadiusMeters (150m). A scan begun before the config resolves, or while the config request is failing, matches point-only patches at the client's local default rather than the admin-configured value, with nothing on screen to say so. It does not produce a false terminal state — the screen has no loading or error surface of its own to get wrong — but the results are quietly computed at a different radius.
• A failed post-import sync still reads as success. The success effect fires syncNow(true) and syncCloudAlbum() and only console.errors a rejection; the gold stamp plays and the modal auto-dismisses after REWARD_HOLD_MS (1100ms) regardless. The claim is safe (it is already in the local pending queue and a later sync pushes it), but the user is told the import landed on the server when it may not have.
• Two number formats on one screen. The scan readout uses toLocaleString() ("1,864 of 4,182") while the no-GPS error prints the raw processedCount ("Scanned 4182 photos but none had location data").
• Confirm skips already-in-progress-elsewhere duplicates: collectPatchBatch checks existingPatchIds at call time and silently drops anything already collected — confirmImport can legitimately report collectedCount: 0 for a non-empty selection if another sync landed those same patches first.

What this feature does NOT do

• Does not earn achievements. UserPatch.source = 'import' is explicitly excluded from IN_PERSON_SOURCE ("gps") in backend/src/achievements/achievements.service.ts:41-47 and feature-context.ts:7-12 — importing your whole camera roll and unlocking 200 patches at once earns zero achievement progress. This is a deliberate, explicit product rule ("Achievements are for being somewhere in person"), not an oversight.
• Does not upload or publish any photo. No image bytes are ever sent to the backend by this feature. Only GPS coordinates and a timestamp travel to /api/location/check-batch and /api/potential-matches. Visit photos stay as on-device MediaLibrary references (VisitPhotoRef.assetId); they are not automatically part of the user's cloud album backup or the public gallery — see the next point.
• Does not write to the public PatchPhoto gallery. backend/src/patch-photos/ is a completely separate upload path (POST /patches/:patchId/photos) that this feature never calls. A photo matched during import only becomes a device-local "My Visit" reference; making it visible to other users (via "publish to gallery") is a distinct, user-initiated action elsewhere in the app, outside this feature's scope.
• Does not perform live GPS tracking or drive the compass. That is a separate always-on background feature (checkPolygons / mobile/src/services/location/tracker.ts); camera-roll import is a one-shot retrospective sweep the user explicitly triggers.
• Does not apply any tolerance/buffer to polygon-backed patches beyond what live tracking gets. The old blanket 10m photoPolygonBufferMeters buffer is gone from the code path; a photo just outside a small building's footprint will not match it, by the same rule that applies to walking up to it in person.
• Does not show the user's real travel route. The "map" animation during scanning is a fixed decorative graphic, not a rendering of the photos' true locations (see Edge cases).
• Does not gate on any feature flag or beta badge — it is treated as a fully mainstream, always-on feature, not an experiment.

Tests that cover it

• Unit / hook tests (mobile, Jest):
  • mobile/src/hooks/__tests__/photoImportSources.test.ts (23 cases) — acquisition, permission branches, page paging, location-read success/failure handling.
  • mobile/src/hooks/__tests__/photoImportMatching.test.ts (9 cases) — accumulator dedupe/earliest-date behavior.
  • mobile/src/hooks/__tests__/visitPhotoCapture.test.ts — visit-photo pair derivation, video/no-asset-id exclusion.
  • mobile/src/hooks/__tests__/usePhotoImport.featureEvents.test.tsx (3 cases) — analytics event firing.
  • mobile/src/utils/__tests__/unified-photo-matching.test.ts (7 cases) — backend-first/client-fallback matching, bucketing.
  • mobile/src/utils/__tests__/mediaAssetRef.test.ts (2 cases) — iOS/Android id translation.
  • mobile/src/components/import/retrace/__tests__/retracePath.test.ts (8 cases) — pure route-geometry sampling.
  • mobile/src/config/__tests__/androidMediaPermissions.test.ts — the Android ≤12 regression guard described above.
  • mobile/src/dev/mocks/import-modal.tsx + the rot guard in mobile/screen-tests/screen-mocks.test.tsx — fifteen gallery states (scout://dev-screen-mock/import-modal?state=<slug>) covering the beats a device cannot reach without a seeded camera roll: invite, choosing-source, choosing-album, requesting-permission, opening-picker, permission-denied, limited-access, tracing, claiming, claiming-none-selected, claiming-all-collected, claiming-large, finishing, no-gps and error. Each asserts a string or testID only that state renders; the patches are 39 real Massachusetts catalog rows (none seeded from an admin_only collection) and only the photographs and the scan counts are synthetic.
  • mobile/screen-tests/import-modal.test.tsx — the screen registry's integration test; explicitly documents that state is local to the hook and can only be driven by real interaction, so it stubs usePhotoImport for the terminal success path and drives the default idle → RetraceInvite render for real; also covers the post-success effect (kicks syncCloudAlbum, does not sync mid-scan).
• Backend tests (NestJS/Jest):
  • backend/src/location/location.service.spec.ts — checkBatch unit-level behavior including photoMatchRadiusMeters sourcing from AppConfig.
  • backend/src/location/location.geometry.db.spec.ts — real-PostGIS fixture tests asserting checkBatch matches via plain polygon containment (no buffer) and via the point radius; the file's own comments narrate the removal of the old buffer.
  • backend/src/location/location.catalog.live.spec.ts — sweeps the real catalogue through checkBatch (interior/exterior points per geometry kind).
• End-to-end (Maestro): mobile/maestro/tests/photo-import.yaml and mobile/maestro/tests/photo-import-android.yaml — drives a real scan against curated GPS-tagged fixture photos (mobile/maestro/fixtures/geo-photos/geo_*.jpg, seeded onto the simulator via xcrun simctl addmedia), asserts nested-boundary matching (a photo at the Saint Louis Zoo unlocking both the zoo and the containing Forest Park patch), and — per this file's own header comment — also absorbed the former album-photo-removal.yaml flow, since removing an imported "My Visit" photo needs an import to have already happened.

Open questions

• photoPolygonBufferMeters remains a live, admin-editable AppConfig key (backend/src/app-config/app-config-schema.ts:63-70) but is not read anywhere in current location.service.ts — it appears to be dead configuration left over from the buffer-removal described in that file's own comments. Unconfirmed whether it's still wired into some other code path (e.g. the single-photo check-in flow) not read for this document, or is simply stale and safe to remove.
• Whether photoMatchRadiusMeters is the only config surfaced in the admin UI for tuning import matching, or whether an admin-facing screen exposes more, was not verified — this document only traces what the mobile client and location.service.ts actually consume.
• The exact wall-clock/UX behavior for a very large library (tens of thousands of photos) beyond the documented 131-photo benchmark was not measured directly for this document; only the code's own stated measurements are cited.