[Bug]: Ignore stale APRS callbacks after tracking stop or reconfiguration

[awatchar]

Problem

An APRS HTTPS request that was already in flight can complete after tracking is stopped or reconfigured and persist stale last-success coordinates again.

Scope

• Introduce lifecycle/config generation ownership for asynchronous sends.
• Ignore success/failure callbacks from a stopped or superseded generation.
• Preserve the T56-only gate, APRS Object format, configured-name fallback, health comment and HTTP 204 plus X-Packetsrcvd receipt rule.
• Do not restore requestSingleUpdate or callsign-owned station positions.

Acceptance

• Tests cover stop-during-send and reconfigure-during-send.
• Stale callbacks do not persist coordinates, counters or schedule obsolete work.
• Existing APRS encoder/manager/policy tests pass.

[awatchar]

Implementation started on branch fix/lab-correctness-batch after reviewing the canonical APRS contract. The change will generation-gate asynchronous results and add stop/reconfigure race coverage without altering T56-only tracking, Object identity or receipt rules.

[awatchar]

Implementation complete in the integration branch: APRS now uses a two-phase generation gate so stop/reconfiguration synchronously invalidates in-flight results. Stale success/failure/permanent callbacks cannot mutate coordinator state, persist a receipt or schedule retry; executor rejection and throwing transport paths release the current attempt. Generation-gate regression tests pass within the 117-test app suite. Physical T56 stop/reconfigure regression remains deferred until hardware is connected.

[awatchar]

Implementation is ready in PR #26.

APRS attempts now carry a generation ticket invalidated synchronously by stop or reconfiguration. Stale success/failure callbacks cannot persist receipts, mutate coordinator state or schedule retries; throwing/rejected transport paths also release the logical in-flight attempt.

Cleanup now attempts removeUpdates() even if location permission was revoked, with the expected SecurityException race handled safely.

JVM gate tests pass. Physical stop/reconfigure regression remains open until T56 is attached.

[awatchar]

PR #26 is merged and the production portal deployment is healthy. This issue remains open only for its explicitly documented hardware acceptance when a radio is attached.