fix: improve wishlist error handling

[thanh251]

Summary

• Distinguish genuine wishlist schema/permission errors from transient Customer Account API failures
• Prevent missing mutation payloads from being treated as successful updates
• Restructure stale-write retries so the final 409 response is reachable
• Preserve the latest known wishlist IDs when retries are exhausted
• Add regression tests for transient errors, permission errors, and missing payloads

Validation

• Unit tests: 27/27 passed
• Wishlist tests: 7/7 passed
• npm run typecheck
• npm run biome
• npm run build
• npm run routes-check
• git diff --check

Closes #39

[hta218]

Verified the error codes against the real schema rather than taking them on trust: APP_NOT_AUTHORIZED, DISALLOWED_OWNER_TYPE and INVALID_TYPE are all valid MetafieldsSetUserErrorCode members and are the setup/permission-shaped ones. GraphQLError.extensions is typed as {[key: string]: unknown}, so the String(... ?? "") wrapper is required, not redundant. Retry restructure is correct: every non-conflict branch returns, so the post-loop 409 is genuinely reachable now. Ran the tests locally, 7/7 pass.

Follow-ups, none blocking:

• Preserving the conflict product IDs has no effect on the UI: wishlist-provider.tsx only applies productIds when there is no error, and the 409 always carries one. Correct as an API contract, but it does not restore anything in the client.
• conflictProductIds = [] and the default conflictMessage are unreachable, since the post-loop return is only reached after a conflict has overwritten both.
• INVALID_COMPARE_DIGEST sits next to STALE_OBJECT in the enum but is not treated as a conflict, so a bad digest returns 400 with no retry. Pre-existing, but adjacent to what this PR restructures.
• The new tests all target writeWishlist; the retry-exhaustion 409 path, the other half of #39, has no coverage.
• tests/wishlist.unit.test.ts is not wired to any npm script, same gap as #43.