[RUM] "AxiosError: Network Error" is never dropped — the endpoint gate needs a resource URL that console-sourced Axios errors never carry

## Summary

`shouldKeepEvent` drops "other network failures" only when it can attribute them to an
instance/cluster operation endpoint via `error.resource.url`. **Every
`AxiosError: Network Error` that actually reaches Error Tracking arrives without that
field**, so the gate has never fired for a single one of them. It is the same
URL-attribution blind spot that #1371 fixed for timeouts — the fix was applied to the
timeout branch directly above and never to this one.

86 events / 24 sessions in the last 7 days; 553 events / 121 sessions in 30 days. With the
browser-extension family from #1645 now filtered, this is the **largest remaining error
family in Studio's Error Tracking**.

Surfaced by the daily automated RUM review (RUM app `f590deee-…`, `env:prod`).

## Evidence

All 86 `AxiosError: Network Error` events in the last 7 days, grouped:

```
86 source=console error.resource.url=absent handling=handled
```

100% — no exceptions. Their handling stacks are React Query's global `onError` calling
`console.error`, which the RUM SDK instruments as an error with `error.source: "console"`.
A `console`-sourced error is not a tracked resource, so it carries no
`error.resource.url`, so `isInstanceEndpoint` is always `false`.

Spread across views (7d): instance table browser 21, scaling 12, apps 11, cluster overview
10, finish-setup 7, and a tail across org/database/sign-in.

## The asymmetry, in the file

`src/integrations/datadog/shouldKeepEvent.ts` — the timeout branch already states the
reason this pattern doesn't work:

```ts
// A request timeout is a connectivity-class failure, never a Studio bug: …
// Unlike the network failures below we drop these unconditionally, because the handled
// AxiosErrors that flood Error Tracking carry no resource URL to attribute them
// to an endpoint. …
if (/timeout of \d+ms exceeded/i.test(message)) {
return false;
}
```

and then, further down:

```ts
const isNetworkFailure = /Network Error/i.test(message) || source === 'network';
if (isInstanceEndpoint && isNetworkFailure) {
return false;
}
```

The comment on the timeout branch is correct and the measurement above confirms it applies
verbatim to network failures: for the events that actually flood Error Tracking, the
`isInstanceEndpoint` half can never be true. The `5\d\d` branch immediately above has the
same shape and the same question hanging over it (all 10 `500` events in 7 days are also `source=console` with no resource URL).

## The open question, which is why this is an issue and not a PR

The obvious edit — drop `isInstanceEndpoint` from the network-failure condition, matching
the timeout branch — makes *more* connectivity failure invisible, and **#1635 is an open
issue arguing that this class being invisible is itself the problem** ("Connectivity-class
failures are deliberately invisible in Error Tracking, so `@type:error` alone
under-reports"). Those two pull in opposite directions and the resolution is a call for
whoever owns the observability story, not something to quietly land:

- **Suppress** — make the network-failure drop unconditional like timeouts. Error Tracking
gets quiet; first-party reachability is then measurable only via
`@type:resource @resource.status_code:0`, which is where #1635 already says it has to be
measured anyway.
- **Keep and attribute** — leave the events in, but give them an endpoint. The
`console.error` in React Query's global handler is the only reason these have no URL;
attaching the failing request's URL to the reported error would make the existing
endpoint gate work as written and preserve the signal for non-instance hosts.

Either way, the current code is not doing what its comment says it does, and shouldn't be
left in that state.

## Also worth noting while touching this file

`console.error` is what puts these in RUM at all — the RUM SDK instruments it directly
(no `datadogLogs` init required, and Studio has none). Any catch block whose purpose is to
keep an expected failure out of Error Tracking must not `console.error`; `console.debug` is
not collected and is the right channel for devtools-only visibility. Recorded here because
generic review advice ("don't swallow it, log it") is actively wrong in this file.

Start in src/integrations/datadog/shouldKeepEvent.ts and compare the timeout, 5xx, and network-failure branches, then read the evidence and the opposing observability concern in #1635. The owner must decide between unconditional suppression and preserving the errors by attributing a request URL. Done means the chosen behavior is implemented consistently and the misleading comment or attribution path no longer contradicts the observed console-sourced events.

Written by the indexing model from the issue text.