Remove runtime secret placeholder validation that breaks deployments

[ChristianPavilonis]

Summary

• Remove runtime placeholder secret validation from Fix weak and inconsistent secret default validation #467 that rejects known placeholder values for synthetic.secret_key and publisher.proxy_secret at startup, breaking previously working deployments
• Keep existing non-empty validation for secret_key — only the expanded placeholder list and case-insensitive matching are removed
• Remove the InsecureDefault error variant, all placeholder detection methods, and related documentation

Changes

File	Change
crates/common/src/settings.rs	Remove PROXY_SECRET_PLACEHOLDERS, is_placeholder_proxy_secret(), SECRET_KEY_PLACEHOLDERS, is_placeholder_secret_key(), reject_placeholder_secrets(), and 6 associated tests
crates/common/src/settings_data.rs	Remove reject_placeholder_secrets() call; replace placeholder-rejection tests with smoke test verifying embedded TOML loads
crates/common/src/error.rs	Remove InsecureDefault { field: String } variant and its status_code match arm
crates/common/build.rs	Remove 4-line comment about placeholder rejection being deferred to runtime
docs/guide/configuration.md	Remove placeholder rejection references from validation, troubleshooting, and security sections

Closes

Closes #526

Test plan

• cargo test --workspace
• cargo clippy --all-targets --all-features -- -D warnings
• cargo fmt --all -- --check
• JS tests: cd crates/js/lib && npx vitest run
• JS format: cd crates/js/lib && npm run format

Checklist

• Changes follow CLAUDE.md conventions
• No unwrap() in production code — use expect("should ...")
• Uses tracing macros (not println!)
• New code has tests
• No secrets or credentials committed

[aram356]

@ChristianPavilonis Please resolve conflicts. Thanks

[aram356]

Summary

Clean removal of the runtime placeholder secret validation that was breaking existing deployments (#526). The deletion is thorough — error variant, constants, methods, tests, docs, and build comments are all removed in lockstep. Non-empty validation for both secrets is preserved.

Blocking

🔧 wrench

• Test asserts placeholder secrets load with no acknowledgement: The replacement test_get_settings asserts that embedded placeholder secrets ("trusted-server", "change-me-proxy-secret") load successfully without explaining why this is expected. Also uses a redundant assert!(is_ok) + expect() pattern. (settings_data.rs:50-56)

❓ question

• No log::warn! for placeholder secrets at startup: The PR removes the hard error but adds zero feedback when cryptographic secrets match known defaults. The existing proxy.certificate_check already uses log::warn!("INSECURE: ...") for the same class of concern. Was a deliberate decision made to have no runtime warning? A warn-instead-of-error approach would unblock deployments while preserving observability for secret_key (HMAC-SHA256) and proxy_secret (XChaCha20-Poly1305). (settings_data.rs:37-43)

Non-blocking

🤔 thinking

• Removing all placeholder detection eliminates defense-in-depth for crypto secrets: proxy_secret is used as a key for XChaCha20-Poly1305 encryption/decryption and HMAC signing. secret_key feeds HMAC-SHA256 for synthetic IDs. A known default key means anyone can decrypt proxied URLs or forge IDs. The issue says "team decided this should be a no-fix for now" — valid for unblocking, but worth noting this removes the guardrail entirely rather than softening it.

⛏ nitpick

• Generic test name: test_get_settings → consider get_settings_loads_embedded_toml_successfully to describe what it verifies. (settings_data.rs:50)

CI Status

• fmt: PASS
• clippy: PENDING
• rust tests: PENDING
• js tests: PASS
• docs format: PASS
• ts format: PASS