POTA/SOTA: add an offline activity catalog and operating-location context

[rtreit]

Parent: #384

Summary

Add an engine-owned POTA/SOTA catalog and lookup surface that supports fast offline logging and can populate the effective operating location for an activation.

POTACAT demonstrates useful POTA behavior with a periodically cached park database, exact lookup, name/reference search, nearby parks, coordinates, distance, and bearing. QsoRipper needs the same capability for both POTA and SOTA without depending on POTACAT.

Catalog contract

Expose program-neutral catalog records containing at least:

• Program.
• Canonical reference.
• Display name.
• Region or association.
• Latitude and longitude.
• Maidenhead grid when supplied or safely derived.
• Source and source version/freshness.

Provide engine operations for:

• Exact reference lookup.
• Typeahead/search by reference or name.
• Nearby activity locations when coordinates are available.
• Catalog status, last successful refresh, and last error.
• Explicit refresh.

Offline and failure behavior

• Cache official POTA and SOTA data locally.
• Logging and activation start must remain usable with the most recent cache when offline.
• Network refresh failures must not block local logging.
• Bound downloads, parsing, storage, and search inputs.
• Do not treat source freshness as proof that a worked portable callsign is currently at that location.

Station context integration

• Selecting a local park or summit can populate the activation location snapshot.
• The effective activation grid/lat/lon must drive station-context consumers such as distance, bearing, and map origin.
• Do not overwrite the permanent station profile simply because a temporary activation is selected.
• Snapshot the selected location onto the activation and QSO station snapshot where required for historical accuracy.

Implementation scope

• Shared proto and service envelopes.
• Rust and .NET providers, cache/storage, and search behavior.
• Configuration and status surfaces required by the engine contract.
• Engine specification and deployment documentation.

Tests

• Recorded provider fixtures and parser tests.
• Exact, prefix, name, and nearby search.
• Cache refresh, stale-cache, corrupt-cache, and offline behavior.
• Grid derivation and station-context snapshot tests.
• Equivalent results across both engines.

Acceptance criteria

• Operators can resolve POTA parks and SOTA summits without a live request in the logging path.
• Activity selection changes effective activation location without mutating the permanent home profile.
• Catalog failure never blocks QSO persistence.
• Both engines expose equivalent lookup and status behavior.