Claude finished @Yeraze's task —— View job

PR Review

• Read changed files
• Review code quality and correctness
• Assess test coverage
• Post final review

Both fixes are clean and well-targeted. Here's the detailed breakdown:

meshcoreManager.ts — LPP WARN label (#3676)

src/server/meshcoreManager.ts:3580-3593

The (LPP) tag added to both logger.warn lines is a minimal, effective change. No logic is altered — just the log message. The comment block above is clear about the intent (non-fatal, the status path is unaffected). No issues here.

Minor nit: the threw variant logs as threw: with error passed as the second argument to logger.warn, which formats differently from the failed: path which interpolates the error message into the string. This is pre-existing behavior and not introduced by this PR, so not a blocker.

telemetryRoutes.ts — 64-hex pubkey bypass (#3677)

src/server/routes/telemetryRoutes.ts:64-69

const nodeNum = /^[0-9a-fA-F]{64}$/.test(nodeId)
  ? NaN
  : parseInt(nodeId.replace('!', ''), 16);
const node = isValidNodeNum(nodeNum)
  ? await databaseService.nodes.getNode(nodeNum, telSourceId)
  : null;

The fix is correct. A 64-hex MeshCore public key has no Meshtastic nodeNum semantics, and isValidNodeNum(NaN) → false, so getNode is correctly skipped and isPrivate defaults to false.

One observation worth noting: the regex ^[0-9a-fA-F]{64}$ is case-sensitive to length=64 only. If MeshCore ever produces public keys in a different encoding (e.g. prefixed, base64), the guard won't catch them. But for the current protocol, 64 lowercase hex chars is the documented format and this is sufficient.

Potential edge case: a Meshtastic nodeId like !<8-hex> with trailing garbage would still fall through to parseInt (not matching the 64-hex pattern), but parseInt with the ! stripped handles that gracefully anyway. No regression risk.

telemetryRoutes.test.ts — Test coverage (#3677)

src/server/routes/telemetryRoutes.test.ts:81-92

The regression test is exactly right:

• Uses 'a'.repeat(64) to produce a valid 64-hex pubkey
• Asserts getNode was not called
• Asserts the response is still 200 with data (i.e., telemetry still flows normally)

The test does not mock databaseService.nodes.getNode, which is fine — vi.fn() returns undefined by default, and the test is asserting it's never called. The explicit not.toHaveBeenCalled() assertion is the meaningful one.

Summary

No blocking issues. Ready to merge.