Three things the page got wrong.
The web-search provider's defaults lived only at their use site, so the
served section carried no value for them and the card fell back to a zero it
invented — a number the schema itself rejects. Declaring them on the schema
makes the settings service the one authority: `maxUses` now reads 5 because
that is what the Host resolves, not because the page guessed. `baseURL` keeps
its code-side default, which exists so `$DEEPSEEK_SEARCH_BASE_URL` can win.
A field the Host serves no value for now renders empty rather than as zero.
The cards were rows in a settings page of cards: name and description ran
together on one line because the shared disclosure row lays them side by side.
Each card now draws its own header, stacking the two, and the section follows
the idiom the Agent Preset page established.
The section knows no namespace: it declares `settings.plugin.item` and
renders whatever cards were registered into it, so a plugin that ships a
browser half owns its card and its controls. The three cards here cover the
host-plane sections this deployment exposes.
A field shows its effective value and, when the raw user layer carries it, an
override badge and a reset that clears it back to the composition layer.
Controls commit on blur and Enter rather than per keystroke, which would burn
namespace revisions and race its own reads. The search key is the one value
that never rides a response: the card reports only whether one is configured
and writes it through the credentials domain, addressed by the reference the
section names.
A card renders nothing while its namespace is unavailable — a deployment that
does not compose the owning plugin should show no trace of it rather than a
disabled card the user cannot act on.
