fix(compiler): key the compile cache by headers and keep the HEX out of the REST response

[ttbombadil]

Purpose

R6 of the refactoring series (docs/UNOSIM_REFACTORING_OPL.md), audit findings A4, A5 and the .incbin channel S1-INCBIN found during R1.

Findings re-verified

• A4 (confirmed): ArduinoCompiler hashed code + fqbn + entryFile without headers, while the compile worker includes headers. In local mode and on the pool fallback, a header-only edit hit the on-disk cache and returned the previous success.
• A5 (confirmed, measured): /api/compile returned binary. The client never reads it.
  • Blink sketch with Serial, HEX 6,019 bytes: the production worker path answered 59,653 bytes (Uint8Array serialised as an object after postMessage); without the binary it is 562 bytes.
  • The same HEX also sat in the in-memory result cache.
• S1-INCBIN: Because the HEX left the server, .incbin in inline assembler could embed a server file into a client-visible payload. That channel closes here.

Change

• ArduinoCompiler uses the worker's buildSketchHash (code, headers, entry file, FQBN). Both paths now share cache entries.
  • libraries stay out of the hash: they are not passed to arduino-cli.
  • Existing direct-path cache entries become unreachable once and are rebuilt.
• /api/compile strips binary before responding and before writing the result cache. ArduinoCompiler itself still returns the binary (toolchain canaries unchanged). The simulation path never used the REST binary.

Tests

• RED → GREEN: arduino-compiler-cache-key.test.ts (header-only change compiles again; a direct compile hits an entry written under the worker identity), compiler-binary-payload.test.ts (fresh response, cached response and LRU entry carry no binary).
• npm run check, check:docs, ESLint, unit 2707 passed, integration-toolchain 14/15 (1 skipped as before), pre-push incl. Sonar quality gate PASSED.

🤖 Generated with Claude Code