POTA/SOTA: add durable activation sessions and ActivationService

[rtreit]

Parent: #384

Summary

Add an engine-owned, durable activation-session model so QsoRipper does not infer activation identity from date and reference heuristics.

This task depends on the first-class portable activity reference model under #384.

Domain model

An activation session must include at least:

• QsoRipper-assigned session ID.
• Program and repeated local activity references.
• Operator callsign and station callsign.
• Station profile or operating-context identity.
• Start and optional end time.
• Active, closed, or equivalent lifecycle status.
• Location snapshot including grid, latitude, longitude, display name, and region or association when available.
• Notes and created/updated timestamps.

QsoRecord must be able to link to an activation session without making the session ID part of ADIF interchange.

Service surface

Add an ActivationService or equivalent engine-owned service with unique request and response envelopes for:

• Start activation.
• Stop activation.
• Get active activation.
• List activations.
• Get one activation.
• Assign or remove a QSO from an activation.
• Export activation ADIF, or expose the bounded QSO selection needed by the export layer.

Follow protobuf 1-1-1 and update the engine specification in the same change.

Behavioral rules

• Enforce at most one active activation per operator/station context by default.
• Starting, stopping, resuming, and retrying requests must have explicit idempotency behavior.
• Logging while a session is active automatically links the QSO and populates the session's local POTA/SOTA references.
• Worked-station references remain explicit QSO input.
• Preserve session snapshots so historical exports do not change when catalog metadata changes.
• Permit corrections, including assigning or removing a QSO after logging.
• ADIF imports without a QsoRipper session ID must not silently create sessions. Any inferred grouping is an explicit, user-approved recovery workflow.

Persistence and parity

• Implement memory and SQLite persistence in both engines.
• Preserve sessions and QSO links across restart and engine switching.
• Define delete, soft-delete, and restore interactions.
• Keep local logging functional when catalog or network integrations are unavailable.

Tests

• Service and storage tests in .NET and Rust.
• Cross-engine conformance for lifecycle, active-context enforcement, QSO linking, correction, restart, and engine switching.
• Concurrent start attempts and idempotent retry coverage.
• Historical snapshot stability tests.

Acceptance criteria

• Activation identity is explicit and durable.
• QsoRipper can select exactly the QSOs belonging to an activation without date/ref guessing.
• Active sessions automatically supply local references without slowing QSO entry.
• Both production engines implement identical behavior.
• The behavior is normative in docs/architecture/engine-specification.md.