Hardened and shared the on-disk Handlebars template compile cache across users - refs #1362

[philayres]

Summary

Stage 1 of issue #1362: hardens and shares the existing on-disk Handlebars template compile cache, without adding any new pre-warmer/scheduled job (that remains a future Stage 2, out of scope here). The compile-on-demand pipeline (compile at request time, cache to disk, serve to the browser) is made safer, disk-bounded, and shareable across users.

What changed

• Atomic writes for all compiled Handlebars artifacts (temp file + rename), so a concurrent reader can never observe partial content and a failed write can never corrupt an existing good file.
• HandlebarsPrecompiler::FileLock: a flock-based, fail-open mutual-exclusion primitive used purely as a work-duplication optimisation (correctness already comes from atomic writes + deterministic filenames), wired into the compile step and multi-bundle assembly to avoid redundant CLI invocations under concurrent requests.
• Content-addressed compiled filenames: compiled output is now keyed on a 32-character digest of the actual preprocessed template source (not on who asked for it), so identical content compiled by different users/app_types shares one file, while differing content is always isolated. This is safe by construction (different content ⇒ different digest ⇒ different file); a related PII-leak vector was found and closed at its source in _search_results_resources_panel.html.erb (and the analogous activity_logs_controller#apply_perspective call site) by restricting a Formatter::Substitution call to only expose role_name, not the full current_user.
• Compiled output relocated from public/ into tmp/ — only the final multi-bundle JS actually served to the browser remains web-servable; individual compiled templates/partials are server-side-only.
• Generation-scoped directories (gen-<key>/) with a count-based sweeper and an opportunistic (no cron) trigger, bounding disk usage across dynamic-definition/config rotations instead of accumulating indefinitely.
• Boot-cleanup guard: the delayed_job worker (and rails console/rails runner) no longer wipes the web server's compiled templates or invalidates its cache on its own restart, since they share disk on Elastic Beanstalk.
• Cross-user test coverage: a new request spec proves, via a real sequence of logins as different users, that users with different access are correctly isolated, users with identical access correctly share a compiled artifact (not just avoid leaking each other's data), and a later return visit is unaffected by intervening users' requests — asserted directly against the compiled files on disk, not just the DOM.

Review process

This branch went through two full independent reviews (via a separate model instance) plus targeted fault-injection testing (deliberately breaking isolation/sharing in the implementation to confirm the new specs catch the regression, then reverting). All blocking and should-fix findings from both reviews have been resolved.

Testing

• Full relevant spec suite (helper, initializer, FileLock, content-addressing safety, cross-user sharing/isolation, dependent view/request specs, system specs) green.
• rubocop clean on every file touched by this branch (verified against the pre-existing baseline — no new offenses introduced).

Refs #1362 (Stage 1 only — pre-warming itself is a separate future Stage 2).