feat(observability): record what the Sentry SDK already instruments before adding a span

[MajorLift]

Motivation

A new timing span is often not a new measurement. The browser SDK already records an http.client span for every request issued while a span is active, so a trace added to time a request can duplicate something already recorded, under a name that claims to measure something wider.

A review that counts trace( sites cannot see any of this. Most child spans are automatic, and a request moved inside an existing trace() callback adds span volume with no instrumentation site in the diff.

Overview

Adds knowledge/auto-instrumentation.md and threads what it establishes through four observability skills.

• knowledge/auto-instrumentation.md records what the SDK creates by default, the parent condition that decides whether a request is recorded at all, how to check whether a proposed timing trace is already covered, and what moves span volume without a trace( site. Sources are pinned to @sentry/* 10.38.0.
• instrumentation gains "check what already records this interval" as the first step, a rule to end a span on the state the UI renders from rather than on the request settling, and what cross-platform parity requires when two platforms emit one name and op.
• sentry-quota stops gating its scan on a pull request looking like instrumentation, and adds automatic child spans to what a reviewer reads.
• sentry-mcp-queries carries the queries used here plus a retention control, since the events API reports dataScanned: full or partial and a truncated window is otherwise indistinguishable from a real result.
• performance-attribution records how trace() routes tags by value type, so a numeric tag never becomes a tag, and how a mismatched trace id produces no span and no error.

Findings came out of the instrumentation review on metamask-extension#46240 and the sweep that followed it.