Integrate reviewed History response admission

Accept exact Web candidate 866da85c26 with parent controls, 379 connected tests, types, build, budgets and inspected browser evidence. Preserve its parent-bound frontend receipt alongside the compatible Core allocation improvement.

Change-source: pulse-maintainer

docs/release-control/v6/internal/subsystems/api-contracts.md

@@ -20,6 +20,33 @@
 
 ## Purpose
 
+### Metrics History responses are bound to the issued selection
+
+The shared History client admits HTTP200 JSON only when the response resource
+type, resource ID, range and single/all-metric shape match the issued request.
+Validation uses a captured selection, not a subsequently mutated params object.
+It preserves only the server's explicit compatibility rules: Kubernetes types
+use the `k8s` wire token, legacy pod IDs receive the `k8s:` prefix and IDs are
+trimmed. An omitted range accepts the empty or 24h default echo; explicit ranges
+and metrics must match exactly. No host, node or disk alias is guessed.
+
+Metrics containers and point arrays must have the declared shape, finite
+readings/aggregate bounds and representable timestamps. Zero and observed empty
+arrays/maps are valid; omitted source remains compatible, and declared store,
+memory, live and mock_synthetic provenance is preserved. Finite but unusable
+window bounds still reach the existing observation-based window fallback.
+Rejected bodies produce a fixed diagnostic without their IDs, values or text;
+body status claims are not HTTP status. Real transport/access failures remain
+unchanged. No endpoint, server permission, collector or wire schema changes.
+
+`chartsHistoryResponse.test.ts` covers the response matrix, legitimate protocol
+variants and mutable input; existing `chartsApi.test.ts` uses actual-shaped
+responses to verify request construction. `HistoryResponse.contract.test.tsx`
+exercises the real client with production drawer, shared chart-state and row
+warming consumers. The connected browser fixture verifies actual History
+components/CSS on desktop Chromium and phone WebKit, not native identity,
+appliance history, workload safety or released availability.
+
 ### Discovery detail reads preserve final access status
 
 `getDiscovery` retains final HTTP401/403 in a typed client error before any

docs/release-control/v6/internal/subsystems/unified-resources.md

@@ -23,6 +23,24 @@ and sort the complete canonical change table while startup and ingestion wait.
 
 ## Purpose
 
+### History consumers do not accept a mismatched or malformed success body
+
+The common metrics History client validates the issued selection and response
+shape before a drawer, shared chart or opportunistic row-history cache can accept
+it. An invalid first HTTP200 is unavailable, not an observed empty series or a
+current-value substitute. A rejected same-target refresh may retain only that
+target's previously validated result with the existing refresh-failure notice;
+rejected values never populate remount or row caches. A valid subsequent read,
+including measured zero or observed empty history, restores normal presentation.
+HTTP401/403 still withdraws cached evidence rather than becoming format failure.
+
+The mounted `HistoryResponse.contract.test.tsx` uses the actual client admission
+boundary, not a mocked ChartsAPI result. `browser-tests/history-response.cjs`
+drives the production PBS-service and disk History fixture with wrong-target,
+wrong-type/range/metric, malformed, denied, valid-zero and empty bodies, keyboard
+retry/inspection and remounts. These synthetic controls do not diagnose #1723,
+establish native panels/identity or prove #2439 thaw or workload liveness.
+
 ### Guest discovery evidence and UI state have exact owners
 
 The guest drawer's passive discovery lookup changes only when its explicit