Admin revoke and disable: a repeated post shows a blank page, and a lost race fails inside the unit of work #2610

Part of #2423 (F-MCP). Found by the review of #2608. Both patterns come from the Agents page and are copied by the Webhooks page, so one fix should cover both.

• A post for an item no longer on the page returns a blank 400. The revoke form on /agents and the disable form on /webhooks are named after the item (revoke-{id}, disable-{id}). Once the item is revoked or disabled, the next render has no form by that name, so Blazor refuses the post before the handler runs. A double click, or a tab opened before someone else acted, shows a blank page instead of "already revoked" or "already disabled", although the action did happen.
• An "already done" race is reported inside the unit of work. AgentCredentialDirectory.RevokeAsync and WebhookDirectory.DisableAsync return the failure for a concurrent revoke or disable after their unit of work began, and their class comments say expected failures are found before it. Nothing nests either call today, but a caller's outer unit of work would then fail to commit.

Scope

• A post for a revoked credential or a disabled webhook renders the page with the "already" message, using a form name that is still on the page or a handler that reads the id from the post.
• The race either commits its no-op unit of work or returns before it, so a caller's outer unit of work can still commit. The class comments are correct either way.

Acceptance

• A second revoke or disable post shows the "already revoked" or "already disabled" message with a 200, on both pages.
• Two concurrent disables inside a caller's outer unit of work leave that unit of work able to commit.