Flaky sub-item rename step in web/e2e/item-crud.spec.ts

# Why?

`web/e2e/item-crud.spec.ts` (added in #363) intermittently fails at its "edit the second sub-item's friendly name" step. Across several CI runs while debugging PR #375, every OTHER step in the same test (create item, numbered default friendly-name assignment, add sub-item, edit family location) reliably succeeded against the real deployed `alpha` backend, confirming the underlying `UpdateItem`/`UpdateSubItem` backend logic itself is correct.

# What?

The specific failure: after filling the sub-item's friendly-name field and clicking Save, the test's `Promise.all([page.waitForResponse(...), page.getByRole("button", { name: "Save" }).click()])` step, followed by `expect(page.getByRole("dialog")).toHaveCount(0, { timeout: 30000 })`, times out waiting for the modal to close.

Trace inspection (downloaded from a failed CI run's `playwright-report` artifact, `0-trace.network`) showed the relevant POST request for that specific save action had **status `-1`** — i.e. it never received a response before the browser context was torn down at test-end, rather than an actual error response. This suggests either:
- A genuine network/Lambda latency spike in that specific run (the `UpdateSubItem` Lambda's first invocation in a fresh test run, similar cold-start rationale already addressed for the family-edit step's own timeout bump in #375), or
- A `waitForResponse` predicate (`(response) => response.request().method() === "POST"`) that isn't scoped tightly enough and could in principle match an unrelated POST from elsewhere on the page, letting the test proceed before the real save response arrives — worth tightening to filter on the response URL/pathname if this recurs.

# Testing

N/A — this issue is about diagnosing/fixing test flakiness itself, not adding new coverage.

# Additional context

Same category as #370 (List History pagination flakiness) — a known-flaky e2e step in an otherwise-passing suite, tracked separately rather than blocking the PR that surfaced it. `item-crud.spec.ts`'s remaining steps (delete sub-item, delete family/cascade) were never reached in the runs observed so far since the test aborts at the first failure; once this step is fixed, re-verify those later steps pass too.