fix: draw the settings on the plugin card, not a click deeper

The page was registered into `plugins.row.config`, keyed
`<package>#<row id>`. That seat puts a page behind the ROW's title button on the
bundle's card — the right home for one row of a bundle that declares several,
and the reasoning the previous commit wrote down. What it missed is that this
bundle declares exactly one row, so its settings became reachable only by
opening the card and noticing that the row title had turned into a button.
Reported from a real install as "it shows the plugin just no settings", while
the sibling plugin's settings were visible: that one registers into
`plugins.bundle.config`.

`plugins.bundle.config` is the same document, dispatched on the card itself:
`PackageDetail` gates a section on `ledger.bundles.has(pkg.name)` and renders
`renderSlot("plugins.bundle.config", { view: "page" }, { entryKey: pkg.name })`
between the description and the rows. So the key becomes the bundle's package
name, and the form draws where someone opening "dsh-recall" is already looking.

The section gets no `form` prop at this seat, unlike the row page — which is
fine, because the card reads its own form from `configForms` rather than
depending on the one handed in.

Verified by serving the bundle from a profile that links this checkout and
reading the artifact back: the served `client.js` carries
`plugins.bundle.config` at the registration and names the retired seat only in
prose. The tests pin the new key and now fail if either the seat or the key
drifts.

README.md

@@ -81,9 +81,11 @@ a fact:
     embeddingApiBase: http://127.0.0.1:11434   # replace with your endpoint
 ```
 
-Or edit every setting from the UI: **Plugins → dsh-recall → Configure**. The
-plugin ships **two halves**, and the page appears only when both are present and
-the deployment serves the namespace:
+Or edit every setting from the UI: **Plugins** in the sidebar → the
+**dsh-recall** card → its settings are on that card, below the description.
+(Not Settings → *Built-in plugins*: that section is a read-only inventory of
+what the deployment ships.) The plugin ships **two halves**, and the section
+appears only when both are present and the deployment serves the namespace:
 
 - the **host half** (`index.js`) exports a `Config` schema whose every field is
   `.volatile()`. That schema *is* the settings page's description — the Harness
@@ -92,11 +94,16 @@ the deployment serves the namespace:
   a schema without those markers has no settings surface at all rather than an
   empty one;
 - the **browser half** (`client/client.js`) renders that form into the Plugins
-  panel's per-row configuration seat, `plugins.row.config`, keyed
-  `<bundle package>#<row id>` — here `dsh-recall#dsh-recall`. Registering it is
-  what adds the **Configure** control to the plugin's row.
+  panel's per-bundle configuration seat, `plugins.bundle.config`, keyed by the
+  bundle's package name. Registering it is what draws the section; without it
+  there is no settings UI however complete the schema is.
 
-A served namespace with no page draws no control, and a page whose namespace is
+The sibling seat `plugins.row.config` — keyed `<package>#<row id>` — draws one
+row's configuration on that row's own page. That is the right home for one row
+of a bundle that declares several; this bundle declares one, so its settings
+belong on the card.
+
+A served namespace with no page draws nothing, and a page whose namespace is
 not served is deliberately not registered — so both are required. A restart is
 needed for a newly installed browser half to appear, because client bundle bytes
 are snapshotted when the profile activates.