Ask whether the person may act as the Bot they named

[beardthelion]

Closes #35.

canAccessAgent says a coworker is reachable when it is public, or the person owns it, or they administer the deployment, and canRunAgent is exported as its alias. Both are called by their own unit test and by nothing else. The roster and the runtime get the rule from the store's read filter; the surfaces that take a Bot id from the request never asked at all, so requireUser was the whole gate on acting as one.

What it does

Asks the store's existing get(actor, id), which already applies the same policy, once per surface rather than once per route. The check arrives as a BotAccessCheck the caller supplies, so a router depends on the question rather than on the agents table, and there is no second copy of the rule to drift from the first.

• Computer: a use on /:botId/*. The session guard moves into the same chain, so a route added later cannot forget either, and the per-route requireUser comes off, which also drops the second session lookup per request. Reads are gated with actions: a screenshot of somebody's Bot is whatever page it is signed into.
• Tool call (POST /api/plugins/call): asked before the grant is looked up. The grant says the Bot may use the tool; it says nothing about who is asking, and the call leaves on the deployment's own credential either way.
• Components: what a Bot may draw, whether it may draw one now, and the data function that runs when it does.
• Listings (GET /api/plugins/for/:agentId, GET /api/components/for-agent/:agentId): a grant list is a fact about the Bot it belongs to.
• Live screen: the websocket upgrade, after the session guard it already had.

Granting is untouched. An administrator putting a skill or a component on a Bot is a different question and requireAdmin already answers it.

A missing Bot and somebody else's Bot answer identically, so none of this can be used to find out which coworkers a deployment has.

A deployment with no profile store has no agents table, so no private Bot to protect, and keeps working.

Verification

16 cases in server/tests/bot-access.test.ts, driving the real routers. Eight refusals fail before the change and pass after, each also asserting that the store, the gateway, or the vendor call was never reached, since a check that runs after the browser has been wiped is not a check.

The cases that must not move are in there too, and passed throughout: the owner still acts, an administrator still reaches any Bot, an unauthenticated caller still gets 401 before anything is asked about a Bot, and a private Bot is indistinguishable from a missing one.

Two existing suites build these routers and now pass a permissive check, because what they cover is the decision and the grant rather than who may ask.

server suite failure set is identical to main (integration tests wanting a Postgres). bun run typecheck and bunx biome check are clean on the changed files.

Not covered by a test: the upgrade in index.ts, which calls serve() at module scope and so cannot be imported by one, and the createApp wiring that builds the check from the real store, which needs a database. Both are the same posture as the surrounding code.