Network: resolve response metadata contract

Goal

Resolve the next concrete Network-plugin metadata question: whether DevLens should capture response Content-Type and/or response size without capturing response bodies.

Issue #17 deliberately left this open after locking URL identity and redaction. This issue is the next Network design boundary, not permission to add arbitrary response inspection.

Current evidence

• @devlens/network currently reports completed Fetch and asynchronous XHR operations with method, canonicalized/redacted URL, status, duration, outcome, and severity.
• ADR-0010 explicitly lists response Content-Type/size without body capture as unresolved.
• The existing Network research treats response bodies and headers as privacy-sensitive and deliberately keeps them out of the default event contract.
• The Panel Inspector already renders generic metadata key/value pairs, so a narrowly defined Network metadata addition would not require category-specific Panel rendering.

Investigation first

Research the browser APIs and actual interceptor behavior for both Fetch and XHR and answer:

1. Can response Content-Type be captured reliably without reading/copying the body?
2. What does "response size" mean at the browser API boundary? Distinguish reliable encoded transfer size, decoded body size, Content-Length, and unavailable/opaque cases rather than collapsing them into one ambiguous number.
3. What information is available consistently for same-origin, cross-origin, opaque, redirected, and failed requests?
4. Does reading headers introduce meaningful privacy or compatibility concerns compared with the current contract?
5. Can the same metadata be captured consistently for Fetch and XHR without changing host behavior or consuming the response body?
6. What should happen for unavailable values: omit the field, use null, or another explicit representation?
7. Is the diagnostic value sufficient to justify adding these fields now, or should one/both remain deferred?

Use authoritative browser/platform documentation where semantics matter and validate uncertain behavior experimentally.

Decision requirements

Produce an evidence-based decision before implementation.

If the contract changes, amend ADR-0010 rather than silently expanding CapturedRequest.

Keep the smallest useful shape. Do not add generic response-inspection infrastructure, body capture, header dumping, or category-specific Panel logic merely because the data exists.

If implementation is justified

• Keep the implementation inside @devlens/network.
• Preserve the existing completed-operation event model.
• Do not read or clone response bodies.
• Do not expose arbitrary headers.
• Cover Fetch and XHR consistently.
• Test unavailable/opaque/failure cases explicitly.
• Verify existing URL redaction/normalization remains unchanged.

Out of scope

• Response body capture or preview.
• Request/response header dumping.
• WebSocket/SSE.
• In-flight request events.
• Endpoint grouping/route-template inference.
• Network analytics UI.
• Changes to Core or Panel unless the final contract proves a real requirement.

Verification

If implementation occurs:

• focused Network tests,
• full pnpm test,
• pnpm build,
• pnpm format:check,
• git diff --check,
• relevant Playground/typechecks.

Do not commit until the research, ADR decision, and implementation diff have been reviewed.

Start with ADR-0010 and the existing @devlens/network Fetch and XHR interceptors. Compare authoritative browser API documentation with focused experiments for headers, response size, opaque responses, redirects, and failures without reading bodies. Record the evidence and contract decision in ADR-0010, then, only if justified, run focused Network tests plus pnpm test, pnpm build, pnpm format:check, and git diff --check.