Indicators: load indicators provided by other plugins

[xxbouncingsoulxx]

What

omarchy.indicators can now host indicators shipped by other plugins. An items entry may be an object naming the plugin and the QML file inside it:

{ "id": "omarchy.indicators",
  "items": ["Dnd", "NightLight", { "id": "Backup", "plugin": "my.org.backup", "source": "Indicator.qml" }] }

The widget looks the plugin up in the shell's plugin registry (installedPlugins[id].__sourceDir) and loads <dir>/<source> (source defaults to Indicator.qml). The file is a normal BarIndicator; the entry's other keys are passed as settings, so the plugin's indicator can be configured the same way as its bar widget.

Why

The indicator group is the right home for "something is going on" state: hidden while idle, revealed dimmed on hover, visible when active. Today only the six first-party indicators can live there; a plugin that wants the same behaviour has to add a standalone bar icon or the user has to clone the whole widget. My use case is a restic backup job: red when the last run failed, green while it runs, hidden otherwise - see screenshots.

Behaviour

• Entries without plugin resolve to ../indicators/<id>.qml exactly as before.
• Unknown plugin id, .. in source, or an absolute source → nothing is loaded and a warning is logged.
• Resolution re-evaluates on registryRevision, so a plugin installed after the bar started is picked up on rescan.

Testing

• ./test/all (CLI + shell suites) on this branch.
• Running on Omarchy 4.0.2 as a cloned widget for a day: stock indicators unchanged, plugin indicator switches active/inactive, hover reveal and click work.

Screenshots: hidden (ok) · failed (red) · running (green) · hover-revealed.

[csfh]

@dhh this could be a potentially reasonable PR if we want to expand a shell plug-in API.