fix(builder): guard unsaved schema changes and repair field deletion

[Morialkar]

Manual QA reported that leaving the schema builder lost work with no warning. Fixing that surfaced a second, unrelated defect in the same screen.

1. Unsaved-changes guard

The builder held every edit in local state and only persisted it through the explicit Save button. There was no dirty tracking, no router blocker and no beforeunload handler, so any navigation discarded the draft silently.

The page now keeps a snapshot of what the server holds, keyed by draft field id, and compares the live draft against it. The baseline is rebased on load, after a successful save-all, after a confirmed deletion and after a confirmed destructive type change, so only genuinely unsaved work triggers the guard. useBlocker covers in-app navigation and, through enableBeforeUnload, tab close and reload.

The canvas also advertised "Brouillon enregistré automatiquement" / "Autosaved draft" — a behaviour that does not exist. That false reassurance plausibly contributed to the reported data loss, so it is replaced by a live saved/unsaved indicator.

2. Field deletion never persisted

Found while verifying the above against the running app, and worth reviewing on its own.

SchemaChangeService::isDestructiveChange treats every field deletion as destructive, so the API rejects a DELETE without a confirmation token. The client only requested a token when preview-impact reported affected records, so deleting a field with no affected records always returned 409. deleteFieldMutation had no onError, so the failure was swallowed — the field disappeared from the canvas and reappeared on reload.

The client now always fetches the token (the impact only decides whether the user is warned first), restores the field and shows an error if the request fails, and apiClient.delete accepts a body so the token can be sent.

This also keeps the guard honest: its baseline assumes a deletion has already persisted.

Verification

Driven against the running stack, not only tests:

• edit a field → indicator flips to "Modifications non enregistrées"; leaving raises the modal; Stay keeps the page and the edit; Leave navigates away
• save → indicator returns to "enregistrées" and navigation is no longer blocked
• delete a field with zero affected records → the field is gone from the API (previously 409, silently)

Also: 63/63 client tests (3 new, covering clean → dirty → blocked and the modal buttons), tsc -b, ESLint, Prettier.

Out of scope

Two adjacent defects are deliberately left for their own changes:

• saving twice in a row duplicates fields, because created fields keep isNew locally
• the Layout tab has its own unsaved state that this guard does not cover

🤖 Generated with Claude Code