[bug] The catalog claims lint runs on agent create but not on update — the path where descriptions actually change #362

The lint runs on create and not on update

lintAgentClaims (#66) is the catalog-integrity check: it flags a description promising a runtime
capability — browser automation, posting/publishing, a local runner, cron/scheduled runs — when the
agent's capabilities declare no runtime and no workflow. Pure, heuristic, deliberately
overridable, and loud.

POST /v1/agents runs it (routes/agents.ts:385) and returns the warnings alongside the 201:

const claimWarnings = lintAgentClaims({ description: body.description, capabilities: {…} });
return c.json(claimWarnings.length ? { id, slug, warnings: claimWarnings } : { id, slug }, 201);

PUT /v1/agents/:id accepts description in its patch body and returns { success: true }. It never
calls the lint.

Why that is the path that matters

Description edits overwhelmingly happen on update, not create — copy gets rewritten as the agent
finds its audience, long after the capabilities were declared. So the realistic sequence is:

1. Create an agent with honest copy and no runtime → clean 201.
2. Later, rewrite the description to "runs a headless browser and posts on your behalf" → 200, no
   warning, published to the catalog.

The check exists, is already imported in that file, and is simply not in the path where the thing it
checks actually changes. #66 framed this as "for a store, a description that overstates what the
agent does is an integrity bug, not polish" — and this is the one surface in the batch that faces
buyers rather than the owner.

Fix

Call lintAgentClaims in the update handler with the post-patch description and the post-patch
capabilities, and return the warnings the same advisory way create does. Both routes should read the
resolved values rather than only body.description — an update that changes capabilities while
leaving the copy alone can create the same mismatch from the other direction, and today neither route
would notice.

Advisory is the right strength; the header calls it heuristic and overridable and that should not
change. This is about the check being present, not about making it block.

Class: the same mismatch as #351, #353, #354, #358 — a surface accepting a claim the runtime cannot
back — seen from the creator side.