release: v0.8.2 — concurrent id lookups reach production

[vaderyang]

Cuts 0.8.2 so the concurrent id lookups from #200 reach production — the only
place that change matters, and the only place it is not yet running.

• VERSION 0.8.1 → 0.8.2, with server/Cargo.toml and console/package.json
  re-derived by just bump patch.
• The Unreleased section becomes the 0.8.2 notes, so release.yml's extractor
  finds a section for the tag (it fails the build when it does not).

No code changes.

What ships

Opening a large agent turn goes 14.6 s → 2.6 s and /api/services/topology
7.5 s → 1.7 s, measured on production data with both binaries against the same
daemon and indexes. The response is byte-identical before and after.

Why this needs its own merge before the tag

release.yml's gate requires staging-soaked and ebpf-soaked on the
tagged commit. This bump is a new commit, so it has to go through
ci → deploy-staging → {staging-soak, ebpf-soak} itself; tagging #200's merge
commit would ship a binary whose --version says 0.8.1, and deploy-prod.sh
refuses to install a binary whose version disagrees with the tag.

One edit beyond the mechanical bump

The draft notes quoted a 376-call turn at 15.7 s and a 418-call turn at 14.6 s.
Both are true — different turns, different experiments a day apart — but side by
side in published release notes they read as though one contradicted the other.
Replaced with the per-call cost the two measurements agree on.

https://claude.ai/code/session_01GxGWpo3L4BRMkwtoa9X54W

[github-actions]

Summary

Pure release PR: VERSION 0.8.1 → 0.8.2 plus the two toolchain-required literals (server/Cargo.toml, console/package.json), the regenerated Cargo.lock, and the Unreleased section promoted to [0.8.2]. The version mechanics are clean and complete, and the changelog accurately describes what #200 shipped — except for one bodies-lookup figure that cannot be true and contradicts the end-to-end number three lines below it. Recommendation: REQUEST_CHANGES (one-line changelog fix; everything else is correct).

Blocking

• CHANGELOG.md:29 — "the bodies lookup goes 14.1 s → 4.1 s at the default limit of 8" is arithmetically impossible against the sentence that follows it: the same paragraph (line 30) says the end-to-end 418-call turn "opens in 2.6 s instead of 14.6 s", and the preceding paragraph attributes "almost all" of the original 14.6 s to that same bodies lookup. A 4.1 s sub-step cannot sit inside a 2.586 s request. The post-change bodies hop is bounded by ~2.6 s total, so the real figure is nearer 2.1 s; 4.1 s appears to be carried over from PR #200's earlier ID_CHUNK=64 microbenchmark ("64 measured 4137 ms … on the real bodies hop"), a different experiment than the A/B the same sentence cites. Why it must be fixed before merge: release.yml:324 extracts exactly this section into the public GitHub Release notes, and the tag is cut from this commit — the wrong number ships as the release's headline claim, and the internal contradiction is visible to any reader in the same paragraph.

Suggestions

• CHANGELOG.md:40 — "(prompted by this investigation)" plus the raw upstream ticket key sglog-ystd puts a third-party tracker ID and a note about Heron's own debugging process onto the public Release page. The key already exists on main in server/h-storage-aglake/src/spl.rs:271, so this is not a new leak, but the changelog is a new surface for it; consider "upstream has since fixed this" without the parenthetical.

Questions

• CHANGELOG.md:19 states the per-call cost as "about 35 ms per call it contained" and the commit message says this replaced the draft's two conflicting numbers because "the two agree on" it — but they don't quite: 15.7 s / 376 ≈ 41.8 ms while 14.6 s / 418 ≈ 34.9 ms. 35 ms reproduces the 418-call turn (418 × 35 ms ≈ 14.6 s) but under-predicts the 376-call one by ~2.5 s. Is the 376-call figure from a differently-composed turn, or should the text say "roughly 35–40 ms" / cite only the 418-call turn?
• CHANGELOG.md:22 quotes /api/services/topology as "6.0–7.5 s" while line 31 gives the after-number as "1.7 s instead of 7.5 s" — is the 1.7 s meant to pair with the 7.5 s end only, or should both ranges match?

Verified

• Version SSOT agreement: VERSION (od confirms 0.8.2\n, no stray whitespace), server/Cargo.toml:11 workspace.package.version, console/package.json:4 all read 0.8.2; bump.sh check_drift would pass. heron --version reads CARGO_PKG_VERSION (server/app/heron/src/main.rs:257), so it will report 0.8.2 and agree with a v0.8.2 tag at deploy-prod.sh's version check.
• Cargo.lock completeness: every workspace member (h-api, h-capture, h-common, h-ebpf-common, h-export, h-llm, h-metrics, h-pcap-extract, h-protocol, h-storage, h-storage-aglake, h-storage-clickhouse, h-storage-duckdb, h-turn, heron) is at 0.8.2; remaining 0.8.x hits are third-party versions (ahash 0.8.12, axum 0.8.8, …), not workspace drift.
• No stale version literals: repo-wide grep for 0.8.1 / 0.8.0 outside .git, Cargo.lock and historical CHANGELOG.md entries returns nothing — install.sh, project.yaml, site/, launch/, _agentops/, docs and CI scripts carry no hardcoded version.
• Changelog→release wiring: the new ## [0.8.2] section is self-contained (Performance + Fixed) and ## [Unreleased] is now empty, so release.yml:324's awk (start at ^## \[0.8.2\], stop at next ^## \[) yields non-empty, correctly-bounded notes.
• Leakage: no private IPs, PEM blocks, credential material, internal hostnames or machine paths in the diff. sglog-ystd is an upstream ticket key, not infra identity (see Suggestions).
• Technical claims spot-checked against the code the notes describe: ID_CHUNK = 64 (spl.rs:297, was 512 at 979f7a2c^), FANOUT_ID_CHUNK = 512 retained for the session fan-out (spl.rs:308), default max_concurrent_searches = 8 (config.rs:983), clamp .max(1) on the shared semaphore (client.rs:793), config validate reports the zero case (config.rs:1507), and concurrency_tests is wired into CI (ci.yml:156).
• Console build surface: the package.json bump is version-only and vite.config.ts:7 derives __APP_VERSION__ from the VERSION file, so no cross-platform build behavior changes.

---

🤖 Reviewed by the review bot • workflow run