Build the Philterd Appliance console as a real application

[jzonthemtn]

The console is 234 lines of static HTML served by nginx, with health probes proxied same-origin so the browser can reach services on the internal network. It lists the products, shows running or unavailable per product, and links out.

That is the right shape and should not grow into something that embeds or re-implements the products. Philter 4.0 already serves its own Vaadin dashboard, Arbiter has its own review UI, and duplicating either would be wrong. But a static page is at its limit, and several things the appliance needs cannot be built on it.

What it cannot do today

• Report anything but up or down. Once the products expose metrics, there is nowhere to put them. Tracked separately in Use product health and metrics endpoints in the console #1.
• Show what the appliance is. No version, no profile, no component list, even though bom.yaml knows all of it.
• Distinguish "not running" from "not installed". Arbiter outside the full profile looks identical to Arbiter crashed.
• Hold any state. No acknowledgement of a warning, no preferences, no history of a service having been down.
• Authenticate anyone. It is unauthenticated and links to products that each have their own login. Unified sign-on across Philter's TOTP and Arbiter's accounts is a real problem and deliberately out of scope here, but the console is where it would eventually surface.

Scope

A launcher and status view, not an aggregating console. It should answer "what is this box running, is it healthy, and where do I go next" and stop there.

The stack is open. Java would match Philter and Arbiter, Go would match the AI proxy and Phield. Whatever is chosen, the contract with the rest of the appliance stays as it is now: the image is named philterd/philterd-appliance-console and it serves port 80 behind the proxy.

Acceptance Criteria

• A decision is recorded on the implementation language and framework
• The console reads bom.yaml, or a rendering of it, so the component list is not duplicated in the UI
• It shows the appliance version and the active profile
• It shows each component's configured version alongside its status
• A product that is not part of the running profile is visually distinct from one that is down
• Health polling continues to work through same-origin probes, with no CORS and no certificate prompt against each product's port
• Probe failures degrade gracefully, including against a product too old to have a health endpoint
• It stays a launcher: no embedding of another product's UI, no re-implementation of its features
• The image name and port contract are unchanged, so nothing else in the appliance has to move
• It renders correctly at laptop and phone widths
• Accessible: keyboard navigable, status conveyed by more than colour alone

Consuming real health and metrics is #1. This issue is the application that would display them.