test: add round-trip invariant and update/delete mutation-failure coverage

[lxbme]

Please answer these questions before submitting a pull request, or your PR will get closed.

Why submit this pull request?

• Bugfix

What changes will this PR take into?

This closes two more "Test-suite gaps" items of the frontend review in #3417.

1. General round-trip invariant (e2e/tests/regression/form.round-trip-invariant.spec.ts)
There was no general "create → read → no-op edit-save → deep-diff" test — the class of bug that #3414 (SSL mTLS client block wiped on edit-save) belonged to. Existing specs pin specific known losses one field at a time; this is the parametrised guard that catches future ones.

For each resource it seeds a rich record via the Admin API, opens the detail page, clicks Edit then Save without changing anything, reads the record back, and asserts it is unchanged. Both sides are Admin-API-stored values (already gateway-canonicalised), so the comparison only drops the server-managed timestamps and folds any array-form upstream nodes back to the object-map form — a benign representation reshuffle is not a false failure, but a dropped or emptied field is.

Covered: route, service, upstream, consumer, consumer_group. SSL and Secret are deliberately excluded — their private key / manager tokens are write-only (never returned by the API), so a pure no-op save cannot reproduce them; the SSL client-block case is already covered by ssls.noop-edit-preserves-client.spec.ts, which re-enters the key.

Note on the consumer case: it seeds username/desc/labels only. A consumer with a key-auth plugin does not round-trip cleanly — a no-op edit-save comes back with a different key (the form appears to drop the write-only key and the gateway regenerates one). This is flagged for separate investigation: if an unrelated edit to a consumer rotates its auth key, existing clients using the old key would break. The harness surfaced it; it is out of scope for this test PR.

2. Mutation-failure feedback for update and delete (e2e/tests/regression/form.mutation-failure-error.spec.ts)
The HTTP-error-with-body toast (via the Axios interceptor) was pinned only for route create. Network-level failures already had update/delete/timeout coverage in network-error.mutation-toast.spec.ts, but the distinct HTTP-500-with-error_msg path was create-only. Two tests are added: an edit-save that gets a 500, and a delete that gets a 500, both asserting the error toast appears.

Related issues

Part of #3417

Checklist:

• Did you explain what problem does this PR solve? Or what new features have been added?
• Have you added corresponding test cases?
• Have you modified the corresponding document?
• Is this PR backward compatible? If it is not backward compatible, please discuss on the mailing list first

The round-trip harness's sensitivity was demonstrated during development: the consumer + key-auth case went red on the changed key before it was narrowed to the non-sensitive fields. Verified with tsc, ESLint, the unit suite, and the full e2e suite.

Remaining test-suite-gap items, each larger and out of this PR: cross-browser / pinned-image CI, and the waitForTimeout removal + parallel-safety refactor.