Fix contest QSO DX target updates

[s53zo]

Summary

Fixes the contest QSO map layer so the latest located contest contact updates the main DX target marker instead of only drawing overlay geometry.

Fixes #832.

Problem

/api/contest/qsos data was being rendered by the Contest QSOs layer, but that plugin only drew markers/arcs. It did not have access to the shared DX target update callback, so the main DX target state stayed stale even when new QSOs were plotted successfully.

Changes

• pass onDXChange through the plugin layer plumbing
• auto-target the latest contest QSO with valid coordinates
• avoid repeated scans and writes by tracking the last handled located QSO
• prevent locked contest QSOs from replaying and stealing the DX target after unlock
• drop unrelated formatting-only changes from this PR

Verification

• npm run build

Notes

DX lock is still enforced by the existing app-level onDXChange handler. This PR only addresses the DX target update behavior. It does not change /api/contest/qsos caching.

[accius]

Thanks for the fix — the approach of threading DX props through the plugin layer plumbing is sound and follows the existing pattern.

A few things to consider:

Substantive

1. DX props now go to every plugin — The PluginLayer change passes dxLocation, onDXChange, and dxLocked to all plugin hooks, but only useContestQsos consumes them. Not a bug (unused props are harmless in JS), but worth noting.

2. dxLocation in the useEffect dependency array causes unnecessary re-runs — Every time the DX target moves (map click, spot click, etc.), the auto-target effect re-evaluates even when there are no new QSOs. It bails early via alreadySelected, but the effect really only needs to fire when qsos changes. Consider using a ref for dxLocation instead of including it in deps.

3. [...qsos].reverse().find(...) runs more often than needed — With up to 200 QSOs, this fires every time the effect triggers (which per point 2 is more often than necessary). Moving dxLocation to a ref would tighten this up.

4. The alreadySelected epsilon check is redundant — The targetKey dedup on the line above already prevents duplicate onDXChange writes. The floating-point comparison (1e-6) across different parse paths is fragile and could be removed to simplify.

Unrelated changes

The formatting-only changes to aprs_newsfeed.user.js, N1MM-SETUP.md, and dxspider-proxy/server.js are fine on their own but add noise to a PR titled "Fix contest QSO DX target updates." Consider splitting those into a separate formatting PR to keep this one focused.

[accius]

also please point this at the staging branch not main

[s53zo]

Addressed the review feedback in this branch update:

• retargeted the PR to Staging
• removed the unrelated formatting-only changes from this PR
• narrowed the plugin plumbing to pass only onDXChange
• removed dxLocation/dxLocked from the contest auto-target effect dependencies
• replaced [...]qsos.reverse().find(...) with a reverse index scan helper
• removed the redundant alreadySelected epsilon check
• track the last handled located QSO so locked contest QSOs are not replayed and steal the DX target after unlock

Verification:

• npm run build