fix: read the settings values, not the references they arrive as

Every field is `volatile()`, which is what puts the settings card on the
Plugins page — and what makes the resolved config carry a reference per field
rather than a value. Every read was a plain-value test (`typeof x === 'string'`,
`Number(x)`, `x !== true`), so all of them were false and the plugin behaved as
if nothing had been configured.

The card displayed and persisted correctly the whole time, because the settings
wire unwraps references for display; only the plugin's own reads were broken.
Reads now go through `configValue()`, and the tool takes a fresh snapshot per
call, which is what lets an edit reach a running instance.

README.md

@@ -294,6 +294,16 @@ invisible to every settings UI, and the `jobs` registry wants `exec.agent.id`
 (a session id) as its owner — handing it the agent object registered a job no
 session could collect.
 
+`volatile()` cuts the other way as well, and this one is easy to miss because the
+page still looks right. A volatile field resolves to a live *reference* rather
+than to a value — that is what lets a save land without re-applying the plugin —
+so `apply` receives an object where the code expects a string, a `typeof` check
+falls through to its default, and the plugin runs on autodiscovery while the card
+displays the settings that were ignored. This bundle reads its own settings
+through `configValue`/`settingsSnapshot`, and the tests that matter resolve a
+fixture through `Config['~standard'].validate` first, because a fixture built
+from plain literals is the one shape a real profile never produces.
+
 Two habits follow. First, this bundle's tests bind to the *installed* harness's
 own slot catalog and package exports, so a rename fails a test instead of
 quietly emptying a page. Second, the browser half keeps its slot and service