[serrrfirat]

Summary

• add host-owned ironclaw_reborn_webui_ingress crate for Reborn WebUI listener lifecycle
• wire ironclaw-reborn serve to validate auth env, build runtime input, and delegate to WebUI ingress
• keep WebUI router composition in feat(reborn): WebChat v2 host gateway — serve loop + auth + routes #3815 and listener binding out of CLI/product API crates

Tests

• cargo fmt --check
• cargo test -p ironclaw_reborn_webui_ingress
• cargo test -p ironclaw_reborn_cli
• cargo test -p ironclaw_reborn_composition --features webui-v2-beta
• cargo test -p ironclaw_webui_v2 --features webui-v2-beta
• cargo test -p ironclaw_architecture
• cargo clippy -p ironclaw_reborn_webui_ingress --all-targets -- -D warnings
• cargo clippy -p ironclaw_reborn_cli --all-targets -- -D warnings

Stacked on #3815.

[gemini-code-assist]

Code Review

This pull request introduces the ironclaw_reborn_host crate to manage the host-side ingress lifecycle for the standalone Reborn binary, including listener binding and graceful shutdown. The ironclaw-reborn serve command has been updated to delegate to this new crate and now requires environment variables for authentication. Feedback identifies a security vulnerability where authentication tokens are compared using non-constant-time operations, which could lead to timing attacks. Additionally, the reviewer noted an issue in the error handling logic where a failure during runtime shutdown could potentially swallow a primary server error.

[gemini-code-assist]

Authentication tokens should be compared using constant-time operations to prevent timing attacks. Using a simple string comparison (==) allows an attacker to potentially guess the token byte-by-byte by measuring response time differences. Use the subtle crate's ConstantTimeEq for a secure comparison.

[gemini-code-assist]

Add the subtle crate as a dependency to enable constant-time comparison for authentication tokens, which helps prevent timing attacks.

[gemini-code-assist]

If both the WebUI service (serve_runtime_webui) and the runtime shutdown fail, the shutdown error will overwrite the primary server error. Per the general rules, the primary error should be returned to the caller, while the secondary failure (shutdown) should be logged as a warning.

References

1. When a primary operation fails and a subsequent cleanup or secondary operation also fails, log the secondary failure as a warning and ensure the original primary error is returned to the caller to prevent it from being swallowed.