Make the admin screens show and say what they are asking (#32)

* Show an administrator what a component grant actually draws

The Components page listed a name, an identifier and a paragraph, and asked somebody to decide from
that whether a Bot should be allowed to answer with it. The one question they arrived with, what
does this put in front of a person, was the one thing the page could not answer.

Each component now introduces itself. `See it` draws the real component, from props it carries
beside its own definition, so a new component cannot be added without deciding how it shows itself
and a preview cannot drift from what it is previewing.

Closed by default. This is a list an administrator scans, and thirteen components drawn at once is a
page nobody reads.

Props rather than tool arguments, because for a component that suspends a run those are not the same
thing: it is handed the whole interaction, `{ status, args, respond }`, and would throw on arguments
alone. A component with nothing to preview says why rather than showing an empty frame, which is the
honest answer for the two that draw this deployment's own records and have nothing to draw until a
Bot asks.

Taken from CopilotKit/openkai. Only the applicable half: the preview and the admin disclosure, not
the visitor demo it was built for.

* Make the admin screens say what they are asking

Three places where the interface named a thing and then relied on somebody already knowing what it
was.

"May read" sat under a row of Bot names, in the same shape as the row above it, and is a different
kind of grant entirely: the row above decides which Bots may draw a component, this decides what
that component may go and fetch in order to draw itself. Read as one switch, an administrator grants
a component to every Bot believing that is all they did. Both rows now say which question they are
answering, and the Bot row says what switching one off actually does, which is that the Bot is never
told the component exists rather than being told no.

The boundary's deny list said "It may never" and offered a CEL box with one example in it. Nothing
named the vocabulary, so writing a second rule meant reading the source. The section now lists what
an expression may ask about, and says the thing an operator most needs to know before typing:
a rule that cannot be evaluated counts as a match, so a mistyped deny refuses rather than quietly
permitting what it was meant to forbid.

"changes things" beside a tool reads as a description of the tool. It is not: it is the effect the
boundary evaluates as `mcp.effect`, and anything not positively known to be read-only gets it, which
is every tool on a server somebody added by URL. That is a governance default nobody could see.

None of this is new behaviour. All of it was already true and none of it was on screen.