fix(registry): serve frontend JS/WASM/CSS correctly in Docker

[toadkicker]

Summary

• get_configuration(None) bakes in site_root = \"target/site\" at compile time; LEPTOS_SITE_ROOT was only used to find the CSS file, leaving JS/WASM served from the wrong path in Docker
• Override leptos_options.site_root at startup from LEPTOS_SITE_ROOT so all Leptos file serving (JS, WASM, CSS) resolves against /app/site in Docker
• Replace the single-file custom CSS route handler with nest_service(\"/pkg\", ServeDir::new(&pkg_dir)) to serve the entire compiled pkg directory uniformly

Test Plan

• All 6 existing pap-registry unit tests pass (cargo test -p pap-registry --features ssr)
• Build Docker image and verify /pkg/pap-registry-ui.css, /pkg/pap-registry-ui.js, and /pkg/pap-registry-ui_bg.wasm return 200 in the container
• Admin UI loads fully with styles and interactivity in Docker

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

The PR fixes a Docker asset-serving bug by overriding leptos_options.site_root at runtime from LEPTOS_SITE_ROOT and replacing the single-file CSS handler with nest_service("/pkg", ServeDir::new(&pkg_dir)) to serve all compiled frontend assets uniformly.

Confidence Score: 4/5

Safe to merge; the fix correctly addresses the Docker path bug with no logic errors.

Only a P2 style observation (no warning when pkg_dir is absent in dev); no P0 or P1 issues found. The site_root override is correctly propagated to both ServeDir and leptos_router.with_state(), and tower_http::ServeDir handles the directory safely.

No files require special attention.

Important Files Changed

Filename	Overview
apps/registry/src/main.rs	Replaces compile-time-baked site_root with a runtime env-var override and swaps the single-file CSS handler for ServeDir over the full pkg directory; logic is sound but the development-mode CSS fallback is silently removed.

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
apps/registry/src/main.rs:320-325
**Development-mode fallback removed without warning**

The old handler fell back to `apps/registry/styles/main.css` when the compiled artifact wasn't found, so the server stayed usable during `cargo run` before a frontend build. With `ServeDir`, any request to `/pkg/pap-registry-ui.css` (or the JS/WASM siblings) when `pkg_dir` doesn't yet exist returns a silent 404, which can be confusing during local development. A startup log line noting that the `pkg_dir` was not found — or a `tracing::warn!` — would help operators and developers diagnose the missing frontend build faster.

_{Reviews (1): Last reviewed commit: "Compiles clean. Here's what was wrong an..." | Re-trigger Greptile}

[greptile-apps]

Development-mode fallback removed without warning

The old handler fell back to apps/registry/styles/main.css when the compiled artifact wasn't found, so the server stayed usable during cargo run before a frontend build. With ServeDir, any request to /pkg/pap-registry-ui.css (or the JS/WASM siblings) when pkg_dir doesn't yet exist returns a silent 404, which can be confusing during local development. A startup log line noting that the pkg_dir was not found — or a tracing::warn! — would help operators and developers diagnose the missing frontend build faster.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/registry/src/main.rs
Line: 320-325

Comment:
**Development-mode fallback removed without warning**

The old handler fell back to `apps/registry/styles/main.css` when the compiled artifact wasn't found, so the server stayed usable during `cargo run` before a frontend build. With `ServeDir`, any request to `/pkg/pap-registry-ui.css` (or the JS/WASM siblings) when `pkg_dir` doesn't yet exist returns a silent 404, which can be confusing during local development. A startup log line noting that the `pkg_dir` was not found — or a `tracing::warn!` — would help operators and developers diagnose the missing frontend build faster.

How can I resolve this? If you propose a fix, please make it concise.

[github-actions]

Benchmark Regression Report

PAP Protocol Benchmark Regression Check
========================================
Baseline: .bench-baseline/baseline.json
Threshold: 55%

  ed25519_keypair_generation                22.1 µs  (baseline: 19.6 µs, +12.6%)  [ok]
  did_key_derivation                         1.6 µs  (baseline: 1.5 µs, +10.0%)  [ok]
  mandate_create_sign                       26.6 µs  (baseline: 23.9 µs, +11.2%)  [ok]
  mandate_chain_verify_depth3              154.9 µs  (baseline: 144.5 µs, +7.1%)  [ok]
  sd_jwt_issue_5claims                      31.0 µs  (baseline: 27.9 µs, +11.2%)  [ok]
  sd_jwt_verify_disclose_3of5               53.2 µs  (baseline: 49.7 µs, +7.0%)  [ok]
  session_open_full_lifecycle              122.5 µs  (baseline: 111.8 µs, +9.5%)  [ok]
  receipt_create_cosign                     53.5 µs  (baseline: 47.9 µs, +11.7%)  [ok]
  federation_announce_local                 66.8 µs  (baseline: 62.0 µs, +7.7%)  [ok]


P99 Tail-Latency Check
----------------------
Results: target/p99_results.json
Threshold: 50%

  session_open_full_lifecycle(p99)         136.8 µs  (baseline: 500.0 µs, -72.6%)  [ok]
  mandate_chain_verify_depth3(p99)         174.9 µs  (baseline: 480.0 µs, -63.5%)  [ok]
  receipt_create_cosign(p99)                63.0 µs  (baseline: 210.0 µs, -69.9%)  [ok]

All benchmarks within 55% of baseline.

_{Threshold: 10% regression vs baseline from main}