Registry: uninstall, update, update-check handlers + admin wiring

[ascorbic]

Registry plugins today only have an install path. PR #1011 added a
"Uninstall is not yet available" note in PluginManager.tsx as a
band-aid. Close the gap.

Parent: #1026

Server

• POST /_emdash/api/admin/plugins/registry/:pluginId/uninstall
  → delete R2 bundle prefix + delete _plugin_state row +
  emdash.syncRegistryPlugins(). Mirrors marketplace shape.
• POST /_emdash/api/admin/plugins/registry/:pluginId/update
  → re-runs the install pipeline at a new version. Requires the
  same consent flow as install (re-confirm capabilities). Uses the
  same idempotency / race protections.
• GET /_emdash/api/admin/plugins/registry/updates → returns the
  list of installed registry plugins whose latest release on the
  aggregator is newer than the installed version. Mirrors the
  marketplace endpoint.

Admin

• PluginManager.tsx:
  • Remove the temporary "uninstall not yet available" note.
  • Enable the uninstall button for source === "registry".
  • Add update flow (capability re-consent if capabilities changed
    between versions).
• Bundle registry update results into the existing updates query.

Tests

• Add the test coverage that was deferred from PR feat(admin): install sandboxed plugins from the experimental registry #1011:
  • assertSafeArtifactUrl SSRF coverage.
  • verifyChecksum multibase encoding + size cases.
  • Concurrent install race (winner keeps R2 bundle, loser doesn't
    delete it).
  • makeRegistryPluginId collision resistance.
  • DID handle resolution edge cases (missing alsoKnownAs,
    handle.invalid sentinel, network failure).

Acceptance

• Uninstall handler deletes R2 + state row, plugin disappears
  from the runtime within one sync cycle.
• Update handler installs a new version, re-confirms capabilities
  if changed.
• Update-check returns the diff list correctly.
• Admin uninstall + update buttons present on registry rows.
• Test coverage matches the marketplace lifecycle tests in
  breadth and depth.