Upstream @effect/platform: restrict http.response.header.* span attrs via allowlist

Problem

@effect/platform's HttpClient tracer hardcodes emission of every response header as a http.response.header.<name> span attribute. For Notion that's ~31 low-signal attrs per span (cf-ray, alt-svc, HSTS, set-cookie flags, …), which drowns useful trace attributes and blows span size.

We currently mitigate via a local patch in packages/@overeng/utils/patches/@effect__platform@0.96.0.patch that introduces HTTP_HEADER_ATTR_ALLOWLIST and only emits listed headers (plus x-notion-request-id etc).

Goal

Upstream the fix so the patch can be dropped. Rough shape:

• Add config on HttpClient.layerConfig / tracer layer to accept a headerAttrAllowlist?: ReadonlySet<string> (or a predicate).
• Default to an empty set — or a very small default of well-known diagnostic headers — to prevent the current firehose behaviour.
• Keep the current behaviour behind an opt-in if backwards-compat matters.

Why file now

PR #584 (notion-react incubation) deleted the local tripwire test (`http-header-filter.unit.test.ts`) that asserted the patch sentinel was present in the installed dist. Downstream pixeltrail trace-quality checks still catch regressions end-to-end, but we'd prefer to stop carrying the patch.

Acceptance

• Upstream PR merged in `Effect-TS/effect`.
• Local patch removed from `packages/@overeng/utils/patches/`.
• Bump `@effect/platform` to the version carrying the fix.

Refs

• Local patch: `packages/@overeng/utils/patches/@effect__platform@0.96.0.patch`
• Original PR context: #584

Start with packages/@overeng/utils/patches/@effect__platform@0.96.0.patch and inspect the referenced @effect/platform HttpClient tracer and layerConfig APIs in Effect-TS/effect. Compare the patch with the upstream implementation and determine the allowlist or predicate configuration needed. Done means an upstream PR is merged, the local patch is removed, and @effect/platform is bumped to the fixed version.