ws-bridged.yaml.example matched nicht dem Parser-Schema

[SandraK82]

Beschreibung

packaging/linux/configs/ws-bridged.yaml.example (was beim Distro-
Install nach /etc/zerodds/ws-bridged.yaml.example kopiert wird, und
auch im fishermen21/zerodds-ws-bridged Docker-Image landet) hat
verschachtelte Top-Level-Keys wie participant.domain_id,
websocket.bind, routes: mit dds_topic:, observability.metrics_bind.

Der echte YAML-Parser in crates/websocket-bridge/src/daemon/config.rs::load_from_str
erwartet aber flache Top-Level-Keys: listen:, domain:,
log_level:, tls:, auth:, acl:, metrics:, topics:.

Da der Parser unbekannte Keys mit _ => {} stillschweigend ignoriert,
fällt die Fehlkonfig nicht durch ConfigError. Bridge bootet einfach
mit Defaults:

[zerodds-ws-bridged] starting on 127.0.0.1:8080 domain=0 topics=0
[zerodds-ws-bridged] auth-mode=none acl-entries=0

User merken's nicht.

Reproduktion

1. Bridge starten mit dem unveränderten example:
   zerodds-ws-bridged --config packaging/linux/configs/ws-bridged.yaml.example
2. Log zeigt 127.0.0.1:8080 domain=0 topics=0 auth-mode=none —
   trotz 0.0.0.0:8080, bidirectional-route, etc. in der Datei.

Spec-Bezug

docs/specs/zerodds-ws-bridge-1.0.md §3 hat das richtige Schema
(listen:, topics: mit direction: bidir). Spec und Parser stimmen
überein — nur das example-File ist veraltet.

Fix-Vorschlag

example-yaml umschreiben gegen das tatsächlich akzeptierte Schema.
Plus: Hinweis in Kommentar dass unbekannte Keys silent-ignored werden
(Tippfehler fallen nicht durch Validation auf).

Optional als Follow-up: Parser sollte unbekannte Top-Level-Keys mindestens
als WARN loggen, damit ähnliche Doku-Drift in Zukunft auffällt.

PR folgt.

[SandraK82]

Fixed in #5 (squash-merged as 01331103).

Root cause: Shipped packaging/linux/configs/ws-bridged.yaml.example used nested top-level keys (participant.domain_id, websocket.bind, routes:, observability.metrics_bind) while daemon/config.rs::load_from_str expects flat keys (listen/domain/log_level/tls/auth/acl/metrics/topics). Parser silently dropped unknown keys via _ => {} — bridge booted with defaults regardless of user config.

Fix:

1. example yaml rewritten against the flat schema per spec §3.
2. Spec ref corrected from §4 (wire-protocol) to §3 (config-file-format).
3. tests/example_yaml_loadback.rs embeds the shipped yaml via include_str! and runs it through DaemonConfig::load_from_str, asserting each key field — future doc-drift now fails CI instead of booting with defaults.
4. Plus the announced follow-up: load_from_str no longer silently ignores unknown top-level keys. Forward-compat is preserved (no ConfigError), but a stderr WARN names the expected keys and points at spec §3. Unit test freezes the forward-compat semantics so any future switch to strict-reject breaks deliberately.

Example output for legacy/typo'd config:

[zerodds-ws-bridged config] WARN: unknown top-level key "participant" ignored
(typo or schema drift? expected one of: listen, domain, log_level, tls,
auth, acl, metrics, topics — see docs/specs/zerodds-ws-bridge-1.0.md §3)

Verification: Internal GitLab pipeline 1064 (13/13 green) + GitHub Actions Build+Test + no_std build.