feat(core): edit saved permissions

[rekram1-node]

Problem

Saved permissions ("Always allow" answers) can be listed and removed through the API, but not changed. To narrow a broad approval, such as a saved shell: *, a client has to delete it, and there is no way to recreate a narrower one. This blocks a UI for reviewing saved approvals (#50600).

Change

Adds PATCH /api/permission/saved/:id (permission.saved.update), which changes a saved permission's action and/or resource. The project can't change, and the rule stays an allow.

 /api/permission/saved
   GET     permission.saved.list
+  PATCH   permission.saved.update   { action?, resource? } → { data: PermissionSaved.Info }
   DELETE  permission.saved.remove

PermissionSaved.update({ id, action?, resource? })
  row = find id                        → NotFoundError  (404 PermissionSavedNotFoundError)
  update row with action/resource replaced
    unique index rejects a duplicate   → ConflictError  (409 ConflictError)
  return updated row

The unique index on (project, action, resource) decides conflicts, so there is no separate duplicate query and no gap between check and write. Bun and Node report the violation with a SQLite code (UniqueViolation). Durable Object SQLite throws a plain Error without codes, so the check also matches SQLITE_CONSTRAINT_UNIQUE in the message; this was verified against the error a local workerd Durable Object throws.

The edit applies to the next permission check, like any saved permission. Requests already waiting are not re-checked, the same as remove.

• packages/core/src/permission/saved.ts: update, plus NotFoundError and ConflictError
• packages/protocol: the endpoint and a new PermissionSavedNotFoundError (the existing PermissionNotFoundError is for pending requests)
• packages/server/src/handlers/permission.ts: maps the core errors to 404 and 409
• packages/client: regenerated

Out of scope

• An endpoint to add saved permissions directly.
• Change events for saved permissions, so other clients refresh live. add and remove don't publish one either.
• How saved permissions rank against a configured ask (today a saved allow wins; see permissions: V2 “Always allow” silently overrides configured “ask” across future project sessions #48456).
• A UI for listing and editing saved permissions.

Verification

• packages/core/test/permission.test.ts: editing narrows what a saved permission allows (the edited resource is allowed, the old pattern prompts again), and conflict and not-found errors. bun run script/test.ts test/permission.test.ts --rerun-each 5: 530 pass.
• packages/server/test/permission-saved.test.ts: creates two saved permissions through the real request and "always" reply flow, then checks PATCH returns the updated entry, the list reflects it, a duplicate returns 409, and an unknown ID returns 404. bun test test/permission-saved.test.ts --rerun-each 10: 10 pass.
• bun run check: 34 of 34 tasks pass.

---

Added by the opencode bot (AI-generated).

Related: #50600

Public API: adds PATCH /api/permission/saved/:id (permission.saved.update) and client saved.update (backwards compatible)

[opencode-agent]

Looks sound. I ran the new server test, which goes through the real request handler and the real "always" reply flow (PATCH returns the updated entry, the list shows the edit, a duplicate gets 409, an unknown ID gets 404), and the core permission tests (106 pass). Type checks are clean in core, protocol, server and client.

Public API: adds PATCH /api/permission/saved/:id (permission.saved.update, payload { action?, resource? } → { data: PermissionSaved.Info }, errors 404 PermissionSavedNotFoundError / 409 ConflictError). Also adds the PermissionSavedNotFoundError error schema, saved.update in the generated effect and promise clients, and PermissionSaved.update, UpdateInput, NotFoundError and ConflictError in core. Additive only, so it is backwards compatible.

One small concern, inline: the duplicate check isn't atomic with the write.

Related: #50600