config.py conflict: #594 discovers plugins before /config/main matches plugin
keys; this branch routes those sections through the /plugins/config
preparation (F13). Kept both.
#594's secret-separation test posts a plugin section to /config/main, which
this branch now validates through api_v3.schema_manager; the test gets a real
SchemaManager over its temporary plugins directory instead of the helper's
mock. It still fails if the discovery call is reverted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The web process discovers plugins lazily: plugin_manifests is empty until
some endpoint calls discover_plugins(). Three routes consulted it without
discovering, so they misbehaved for as long as nothing else had run --
which, after every ledmatrix-web restart, is until someone opens the
dashboard:
- POST /display/on-demand/start answered 404 "Plugin <id> not found"
(or "Mode <mode> not found"). Measured on a rig: 404 for over three
minutes after a web restart, until GET /plugins/installed ran. The
browser UI loads the plugin list first, so API-only callers (the Home
Assistant MQTT bridge, scripts) are the ones who hit it.
- POST /plugins/toggle answered 404 "Plugin not found".
- POST /config/main did not recognise a plugin section, so it skipped
secret separation and merged the section as-is: the plugin's API key
was written to config.json in plain text instead of config_secrets.json.
Add _discovered_plugin_manifests(), which discovers when nothing has been
yet, and rescans once when a specific plugin id (or, for on-demand by
mode, a mode) is not found, so a plugin installed since the last scan is
found too. _installed_plugin_ids() now uses it.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
