Non-blocking review findings from PR #297 (2)

[twistedmelonman]

Non-blocking concerns raised while reviewing PR #297 (feat(finicky): generate finicky.js from installed Chrome PWAs).

None of these blocked the merge. They are batched into one issue so a
review's findings stay one unit of attention rather than 2 separate
tracking issues; tick items off as they are addressed, and close this issue
when the list is done or the remaining items are judged not worth doing.

• Stale temp dir may be left behind when the validation copy fails in generate-config.sh (claude (automated blocking review, comment on sha 8408e5f), finicky/generate-config.sh — validation path (_validate_rendered))
  The bot's review states that the temp dir created by _validate_rendered is cleaned up in both normal branches, but that a cp failure would leave a stale temp dir behind. It characterized this as no data-loss risk, which is why it did not block. Worth a small follow-up to move the temp-dir removal into a trap or an unconditional cleanup path so a failed copy cannot leak a directory under TMPDIR. Note the PR's own test suite asserts no finicky-check.* temp files remain on the success path only.

• FINICKY_RESTART_CMD is shell-executed via bash -c (claude (automated blocking review, comment on sha 8408e5f), finicky/generate-config.sh — restart hook after install)
  The bot notes that FINICKY_RESTART_CMD is passed to bash -c, so its contents are evaluated as shell. It judged this non-blocking because the variable is set only in the test suite and production always falls through to _default_restart. Tracking it as a reminder that the variable is an intentional test seam, not a supported user-facing configuration knob — documenting that in the script header would keep someone from wiring untrusted input into it later.