[RUM] shouldKeepEvent's isInstanceEndpoint branches are dead: this SDK never emits source:network errors (0 in 30d vs 592 direct status-0 resources)

## Summary

`shouldKeepEvent` (`src/integrations/datadog/shouldKeepEvent.ts`) has two branches gated on `isInstanceEndpoint` — a URL match on `error.resource.url` — that drop 5xx, bare-timeout and network failures against the central-manager proxy shape `/(HDBInstance|Cluster)//operation`. Its header explains that connectivity errors "reach RUM two ways: as tracked resource errors (which carry an `error.resource.url`) and as handled AxiosErrors surfaced through `console.error`".

The first way does not exist in the SDK Studio ships. Those branches never fire, and the model they encode has now misled two reviews.

## Evidence

- **Production, 30 days to 2026-09-08:** `@type:error` splits into `source` 4,472 / `console` 1,828 / `custom` 155 — **zero** `@error.source:network`, and **zero** errors of any source carrying `@error.resource.url`. The underlying failures do happen: 592 status-0 and 24 status-500 `@type:resource` events against direct `:9925` hosts in the same window. Nothing turns them into error events.
- **SDK:** `@datadog/browser-rum` 7.8.0 (core 7.6.1). `browser-core` still declares `ErrorSource.NETWORK`, but nothing in `browser-rum-core` emits it — there is no network-error collection module. Failed XHR/fetch calls are recorded as resources with a status code, not as errors.

So the only way an instance/cluster failure reaches Error Tracking is the `console` path (React Query's global `onError` → `console.error`), which never carries a resource URL — exactly the case the header says the URL gate "cannot see".

## Why it matters

- The review of #1680 (both the cross-model adjudicator and a human reviewer) concluded that pointing the sign-out logout at the instance's own URL would route stopped-instance failures into Error Tracking "through the other door", because a direct URL does not match the proxy shape. That door is not there. The same reasoning would send anyone extending the filter for direct-connect traffic down a dead path.
- #1635 already records the consequence from the other side: direct-to-instance connectivity failures are invisible in Error Tracking, and `@type:resource @resource.status_code:0` is their only trace.

## Suggested direction

Delete the two `isInstanceEndpoint` branches and rewrite the header so it states the actual model: RUM errors here come from thrown exceptions (`source`), `console.error` (`console`) and `addError` (`custom`); resource failures are resources, not errors. If a future SDK upgrade reintroduces network-error collection, the RUM daily review will see a new `source: network` bucket and the gate can come back with a test that constructs such an event.

## Related

- #1680 — where the false premise surfaced (its PR body's reviewer note about the "resource-error path" is wrong for the same reason).
- #1635 — the class being invisible in Error Tracking.
- #1371 — the flood the URL-less `console` path caused, which is the real route.

Start in src/integrations/datadog/shouldKeepEvent.ts and read the header and isInstanceEndpoint branches. Confirm the current filtering behavior and remove the dead branches while documenting that RUM errors come from source, console, and custom paths, not resource failures. Done means the obsolete URL-gated logic and misleading model are gone.

Written by the indexing model from the issue text.