fix(packets): show all ambiguous endpoint candidates

[n30nex]

Packet endpoint chips discarded all but the first match, which could make an ambiguous TXT_MSG source/destination look conclusive. Show an additional-match count and reuse the existing hop popup to list every candidate on hover, keyboard focus/activation, or touch. Opening a chip no longer also selects its packet row. Logical endpoints also render without physical path metadata.

Closes #74.

Four regressions failed first and now pass. The complete frontend build/lint/874-test suite passes on Windows and native Pi ARM64. No protocol direction change: the current decoder correctly reads destination then source; ambiguity was hidden by presentation. No new dependency or server contract.

AI-assisted implementation and validation under n30nex's standing project authorization. Please review the focused diff; no specific human review of this new diff is being claimed.

Current integration (28 September): the queue is refreshed onto accepted web dev 17f48fb9. Parent 17f48fb932facbdcc45068afd2db6036ac2ec94d, published head e65e8e42ec7bcd75029ebc636645eedc2b889cbf. Focused diff. Build/lint/tests pass for this refreshed tree and actual-head build CI passes (repository CodeQL skipped). The full web composition 6b688495 is now deployed on Pi server 2ed2e031, retaining every candidate. Its native build/lint and all 935 tests pass; all 18 public assets and both source archives match. Web assets are byte-identical to the previously geometry-tested build; fresh English desktop/French phone and Public-message packet inspection pass. Current evidence and recovery. Earlier feature-specific validation above is historical. No feature behavior changed in this base refresh.

[n30nex]

@MrAlders0n, please review this focused ambiguity fix (and have Claude review it if useful). It targets current dev and has no server PR dependency. Native Pi build/lint and 874 tests passed for 3a18e6d. The formal review-request API is not available to this contributor account, so I am requesting review here.

[MrAlders0n]

Nice. It keeps the backend confidence and doesn't pick a winner. One thing before merge:

• PathData.tsx:98-110: the chip is now a role="button" tabIndex=0 span, but PacketEndpoints renders inside the row's <button> (PacketTableRow.tsx:37-61). A focusable element inside a button isn't valid HTML. It adds up to two Tab stops per row, and screen readers merge the chip into the row's name. Please keep it hover/tap only, like the path chips, with a title that lists the candidates.

Minor:

• path-summary.ts: nothing reads source/destination/endpointChip now except their own test. Please remove them, and fix the stale comment at PacketTableRow.test.tsx:17.