Only reload local plugins when loadable sources change

[DonnieFi]

Summary

• Allowlist the local plugin filesystem watcher to manifest.json / *.manifest.json / *.qml / *.js so runtime state writes (e.g. data.json, caches, binaries) no longer tear down the whole bar.
• Filter both in inotifywait --include and in localPluginIdForPath as defense in depth.
• Update docs and registry contract assertions for the new behavior.

Fixes #12158

This is intentionally an allowlist rather than extending the denylist approach in related PRs like #12020 / #10705 — those still fire on arbitrary files such as data.json.

Test plan

• bash test/shell.d/plugin-registry-contract-test.sh
• Smoke-tested inotifywait --include '(manifest\.json$|\.manifest\.json$|\.(qml|js)$)' — data.json suppressed; .qml / manifest.json / .js still fire
• Manual: install/enable a plugin that writes runtime state under its plugin dir and confirm journal no longer floods with Local plugin changed, reloading
• Manual: edit a plugin .qml / manifest.json and confirm hot-reload still works

[sprajs]

The new filter also suppresses whole-plugin directory moves. I checked inotifywait in a temporary tree: moving a pre-populated directory containing manifest.json into plugins/acme.clock emits the directory path with the old watcher, but emits nothing with this PR's --include regex. There is no separate manifest write for the filter to catch. localPluginIdForPath() now rejects that directory path as well.

Could directory create/move/delete events remain eligible for rescanning while runtime-file writes stay filtered? A regression test that moves a populated plugin directory into the watched tree would cover this without needing a running desktop.