[No ticket — safety-net 312883915] Stop reporting cancelled-request AbortErrors as network failures

[cru-self-healing-agent]

Description

• Triaging Datadog safety-net monitor 312883915 "MPDX React frustration rate by page [prod]" (no Jira ticket exists for this alert — identifying the monitor here instead, per the monitor's own runbook).
• The monitor fired on two routes: /accountLists/?/tools/fix/commitmentInfo (30.8% vs an 18% threshold) and /accountLists/?/reports/expectedMonthlyTotal/? (34.6%). Reproducing the monitor's own a / (b + 20) * 100 formula against RUM confirmed both genuinely crossed — every other route sat at ≤6.8%, in line with the monitor's stated normal range (~4.7–7%).
• Breaking the frustration actions down by @action.frustration.type + @action.target.name showed 100% of it was error_click (a click immediately followed by a JS error) on the "YES" confirm button and "Amount" field (commitmentInfo), and on "Edit Partnership Info"/"SAVE" (expectedMonthlyTotal). Every single @type:error RUM event on both routes in the breach window had the identical message: "The user aborted a request." — a standard fetch AbortError.
• That error is not auto-captured browser noise — it's manually reported. src/lib/apollo/client.ts's global Apollo onError link treats every networkError (including AbortError, which fires whenever a request is cancelled by navigation, component unmount, or a batched request sharing an in-flight fetch with one that got cancelled — normal SPA behavior) the same as a genuine API failure: it shows the user snackNotifications.error(networkError.message) (the raw, confusing "The user aborted a request." text) and reports it to RUM via reportNetworkError/addDatadogError. That's what turns an ordinary, harmless cancellation into a "did my click work?" moment that drives repeat clicking, and what makes Datadog tag those clicks as error_click. There is no AbortController anywhere else in this app's own code, so every abort observed here is Apollo/browser-cancellation noise, not something the user or an API caused.
• Fix: in the onError link, skip the dispatch/snackbar/RUM-report for networkError.name === 'AbortError'. Genuine network/GraphQL errors are unaffected.
• Related: open PR [No ticket — safety-net 312883915] Call cache.gc() after evicting Contact in FixCommitmentInfo #2011 (fix-commitmentinfo-cache-gc, from the self-healing agent, also based on this same deployed version and tagged to this same monitor) adds a missing cache.gc() call after evicting a Contact in FixCommitmentInfo. That's a legitimate cache-hygiene gap, but it doesn't match this alert's evidence (different error type entirely — no AbortError involved) and doesn't touch expectedMonthlyTotal at all, so this PR is not a duplicate of it.
• No Jira ticket exists for this alert.

Testing

• Go to any page that issues a GraphQL query/mutation (e.g. /accountLists/[id]/tools/fix/commitmentInfo).
• Trigger a request and cancel it before it completes — e.g. click "Confirm"/"Yes" on a contact and immediately navigate away, or throttle the network and click a Save/Confirm action then click a different app link before the response returns.
• Before this change: an error snackbar reading "The user aborted a request." appears, and the operation is reported to Datadog RUM as a network error.
• After this change: no snackbar appears and no RUM error is reported for the cancelled request; a genuine network failure (e.g. take the network offline and submit a mutation) should still show the error snackbar and still report to RUM, confirming real failures are unaffected.
• I could not run the test suite, typecheck, or linter in this container (no installed dependencies/generated GraphQL types) — please run the existing src/lib/apollo test suite and confirm no regressions.

Checklist:

• I have given my PR a title with the format "MPDX-(JIRA#) (summary sentence max 80 chars)" — no Jira ticket exists for this alert; title instead identifies the safety-net monitor (312883915) per the monitor's runbook.
• I have applied the appropriate labels (Add the label "Preview" to automatically create a preview environment)
• I have run the Claude Code /quality:agent-review command locally and fixed any relevant suggestions
• I have requested a review from another person on the project
• I have tested my changes in preview or in staging
• I have cleaned up my commit history

[github-actions]

Bundle sizes [mpdx-react]

Compared against 424b0c2

No significant changes found