feat(nodes): name the position source on the Node Details badge (#4498)

[Yeraze]

Closes #4498.

The Position card showed a generic "GPS" for every real fix. The protobuf's location_source (LocSource) has been decoded, stored and formatted since #4176, but PR #4188 wired it only into the map popups — NodeDetailsBlock was never updated, so a manually-entered fix and an internal GPS fix looked identical.

Wires the existing formatLocationSource() into the gps branch, so the badge reads Internal GPS / External GPS / Manual. The helper returns null for LOC_UNSET or an absent value, so nodes that never reported a source keep the exact pre-#4498 wording.

The "Exact" bonus, done differently to what the issue proposed

The issue suggests labelling the null-accuracy case "Exact". Implemented, but not as a blanket rule — hasAccuracyCell() returns false for three different reasons:

reason	genuinely exact?
full precision (bits ≥ 32)	✅ yes
user override	✅ yes
unset / zero precision bits	❌ no — unknown

Only the first two are exact. The third means the device never told us how precise the fix was, and labelling it "Exact" would assert something we don't know. So the unknown case still renders nothing, and a test pins that specifically.

Test plan

• 9 new tests — LocSource 1/2/3 naming, generic "GPS" for unset/absent, Override still outranking LocSource, Exact for full precision and for overrides, nothing for unreported precision, error bar for an imprecise fix.
• Confirmed real regressions: 5 fail without the change; the other 4 guard unchanged behaviour and correctly pass either way.
• Full Vitest suite — success: true, 13007 passed, 0 failed.
• npx tsc --noEmit clean; npm run lint:ci no FAIL lines.

---

Generated by Claude Code

[github-actions]

Claude finished @Yeraze's task —— View job

---

PR Review: feat(nodes): name the position source on the Node Details badge (#4498)

Tasks:

• Gather context
• Read changed files
• Review code quality and best practices
• Check for bugs/issues
• Review test coverage
• Post final feedback

---

Summary

This is a clean, well-scoped PR. The implementation logic is sound and the test coverage is comprehensive. A few minor observations below.

---

NodeDetailsBlock.tsx

Minor: formatLocationSource called twice for tooltip generation

src/components/NodeDetailsBlock.tsx:208

tooltip:
  formatLocationSource(node.positionLocationSource) !== null
    ? t(
        'node_details.position_source_gps_tooltip_sourced',
        'Position reported by the device ({{source}}).',
        { source: formatLocationSource(node.positionLocationSource) },
      )
    : ...

formatLocationSource is called twice with the same argument — once to check for null and once to fill the template. The helper is a pure switch so no correctness risk, but it's mildly wasteful. A local const locSourceLabel = formatLocationSource(node.positionLocationSource) before the object literal would make the gps branch cleaner and avoid the duplication:

: (() => {
    const locSourceLabel = formatLocationSource(node.positionLocationSource);
    return {
      kind: 'gps',
      label: locSourceLabel ?? t('node_details.position_source_gps', 'GPS'),
      tooltip: locSourceLabel !== null
        ? t('node_details.position_source_gps_tooltip_sourced', 'Position reported by the device ({{source}}).', { source: locSourceLabel })
        : t('node_details.position_source_gps_tooltip', 'Position reported by the device.'),
      ...
    };
  })()

Not a blocker — just a readability nit.

---

Minor: JSDoc comment inside the positionSource object literal

src/components/NodeDetailsBlock.tsx:151–166

The exact property has a multi-line JSDoc block inside the type annotation of a const declaration. While legal TypeScript, the comment sits in an unusual location (inside the type literal). It's informative and matches the PR description well, but might be better placed as a comment on the positionSource const itself or the exact property assignment for readers scanning the code. Very minor style point — your call.

---

NodeDetailsBlock.position.test.tsx

Good:

• The it.each parameterized approach for LocSource 1/2/3 naming is clean and easy to extend if new sources are added in the future.
• The three-way loop for undefined, null, 0 in the "unknown is not exact" test is a thorough guard.
• The table in the PR description explaining the three hasAccuracyCell() == false cases is excellent documentation — it would be worth preserving in a code comment too (which you've effectively done in the JSDoc at NodeDetailsBlock.tsx:157–165).

Minor: Test for Override priority could also verify tooltip

src/components/NodeDetailsBlock.position.test.tsx:190–200

The test verifies Override text appears and Internal GPS does not, but doesn't check whether the tooltip is the Override tooltip. The positionSource.tooltip is set conditionally and the Override tooltip copy differs from the GPS one. This is purely additive and not a regression concern — just a note if you want exhaustive tooltip coverage.

---

Correctness Assessment

The logic in the gps branch is correct:

• formatLocationSource correctly returns null for LOC_UNSET (0), absent, and any unknown enum values — so the fallback 'GPS' is only applied when needed. ✅
• The exact flag uses positionPrecisionBits >= 32 (not === 32) which correctly handles any value ≥ 32. ✅
• hasAccuracyCell correctly returns false for isOverride: true, which means the override branch setting exact: true with accuracy: null is consistent and will show "Exact". ✅
• The Priority chain (positionIsOverride → positionIsEstimated → GPS) correctly mirrors enhanceNodeForClient server-side logic. ✅

---

Security / Performance

No concerns. This is purely a presentational change — formatLocationSource is a simple switch over an already-stored integer, and hasAccuracyCell is two comparisons. No network calls, no raw SQL, no sensitive data exposure.

---

Verdict

Approve with the nit above. The double-call to formatLocationSource is the only thing worth changing; everything else is well-done. The test suite is particularly thorough — calling out that "unknown precision is not the same as exact" in both the PR description and the test comments is exactly the kind of defensive documentation that prevents future regressions.