fix: confirm deletes and refuse duplicate Provider IDs

[yujiezhang-ops]

Closes #86. Closes #87.

Delete confirmation and idempotent Profile delete (#86)

Deleting a Profile ran straight from the button's onClick — no confirmation, no undo — and the button was never disabled while the request was in flight. A double-click sent two deletes, and the second found the file already gone and surfaced Unknown Profile for a Profile that had just been deleted successfully. That error is what got reported.

Store.Delete now treats an already-absent Profile as success: the caller asked for it to not exist and it does not. The secret and the active pointer are still cleaned up, so a record that vanished out-of-band no longer becomes undeletable either.

Both delete buttons (Profile and Provider) gain a confirmation and a disabled={busy} state. The confirmation reuses the native Wails dialog that the update prompt and export flow already use rather than introducing an in-app modal — it is modal for free, cannot be dismissed by a stray click, and needs no styling in either theme. Neither button is IsDefault, so an accidental Enter does nothing.

The existing test here was fake. "deletes a Profile after confirmation" stubbed window.confirm, which the page never called, so it passed against a delete with no confirmation at all — precisely the bug it was named for. Replaced with the decline path, the accept path, and a second click while the first delete is in flight. The decline case is what makes the confirmation load-bearing; without it, deleting unconditionally still passes.

Duplicate Provider IDs (#87)

Saving a Provider was an unconditional upsert with only the literal ID custom reserved. Reusing an ID silently replaced that Provider's endpoints and key, and an ID matching a built-in shadowed the catalog entry — after which SaveProvider reapplies the Provider to every Agent bound to that ID, so a typo could repoint working Agents at another vendor's endpoint with no prompt.

Creating and editing are now distinct. That has to come from the caller: both arrive as a complete Entry, and an ID absent from disk is equally consistent with creating and with renaming, so the store cannot infer it. Store.Create refuses a taken ID (user or built-in); Save stays an upsert, which editing and key rotation need. The import path passes create: false deliberately — restoring a backup is supposed to overwrite.

The form no longer asks users to invent an identifier: it arrives prefilled with a free valid ID and states the rule inline instead of teaching it by rejection.

A silent bug found while verifying

The pattern attribute on all three ID fields had never worked. Browsers compile pattern as a v-flag regex, where a literal - inside a character class is a syntax error — so validation threw, the browser swallowed it, and the attribute accepted every value including ACME!!. Invisible because the Go validator caught bad input at save time. Escaping the hyphen restores client-side validation. The regression test reads the attributes out of the source and compiles them under v, rather than rendering the components, because the bug is in the attribute string: a DOM-inspecting test would assert a value the browser had already rejected.

Testing

• go test ./... — all packages pass; go vet ./... clean
• pnpm run test — 31 files / 234 tests pass
• pnpm run build (includes tsc --noEmit) — pass

New Go coverage for DeleteProfile (normal delete removes the secret too, repeat deletes succeed) and for Store.Create (duplicate user ID and built-in ID both refused, and the original survives untouched).

Manually verified against the e2e fake-runner server: the prefilled ID appears with the rule beneath it, saving a Provider with ID ppio is refused with a readable message while PPIO stays unmodified, and the delete confirmation blocks the delete. Regenerated frontend/bindings with the pinned CLI per build/Taskfile.yml; the only change is the new create field.

🤖 Generated with Claude Code