manifest: services: {database, kv, websocket} are parsed and never acted on

[luthermonson]

A manifest's services: block looks like it provisions things. It provisions nothing.

services:
  database: "turso"
  kv: true
  websocket: true

There are three uses of these values in the entire crate: a tracing::info! field, and the .switchboard-preview.json sidecar. ePHPm never reads the manifest. kv: true turns nothing on; database: false turns nothing off. Whatever the app gets, it gets from the node's ephpm.toml and from being a vhost — identically, whatever the manifest says.

This is the house rule from ephpm's CLAUDE.md, applied to switchboard: a new config field must be read and enforced by code in the same PR; if it genuinely can't be, the doc comment must say "Planned: not yet implemented — parsed but not acted upon" AND startup must warn. Neither holds here.

It is the same defect class as ephpm#429 (a [db.sqlite] key that parsed and silently did nothing), ephpm#473 (middleware config keys dropped with no log), and switchboard#23 (seed steps dying silently) — an operator's explicit instruction becoming a no-op with every health check green.

Found while writing the ephpm.dev onboarding page (ephpm/ephpm#474); the page deliberately does not claim these keys do anything.

Suggested direction

Pick one and make it true:

1. Enforce them — refuse to deploy when the app asks for a service the node cannot provide (kv: true on a node with no KV configured is a preview that will fail at runtime in a way the app author cannot diagnose). This is the useful version: it turns a runtime mystery into a deploy-time error naming the missing service.
2. Demote them — document as advisory metadata only, warn at deploy when set, and stop them looking like switches.

(1) is more work and more valuable, since the manifest is written by someone who does not control the node.