chore(main): release clickhouse-migrator 0.1.0

[e2b-release-please]

🤖 I have created a release beep boop

0.1.0 (2026-07-31)

Features

• dynamic sandbox log routing and ClickHouse-backed log reads (#3236) (1b19a3b)

---

This PR was generated with Release Please. See documentation.

[claude]

Approving — this is an auto-generated release-please chore PR (manifest version bump + changelog entry), and the only issue found is a cosmetic duplicate CHANGELOG section (pre-existing manifest/changelog desync from a prior release PR), not a functional problem.

Extended reasoning...

Overview

This is a standard release-please automation PR bumping packages/clickhouse from 0.0.1 to 0.1.0 in .release-please-manifest.json and prepending the corresponding entry to packages/clickhouse/CHANGELOG.md. No application code is touched.

Security risks

None. The diff is limited to a version manifest JSON file and a markdown changelog — no code, config, or credentials are affected.

Level of scrutiny

Minimal scrutiny is appropriate here. This is fully mechanical, bot-generated release tooling output with no logic changes. The one inline finding (duplicate "## [0.1.0]" section in the CHANGELOG, caused by a manifest/changelog desync introduced in a prior release PR #3300) is purely cosmetic documentation noise — it doesn't affect any code path, since tooling relies on the manifest (which is correct and singular after this merge), not on parsing CHANGELOG.md.

Other factors

No prior reviews exist on this PR. Merging this PR actually resolves the manifest desync going forward (manifest will correctly read 0.1.0), so blocking on the cosmetic duplicate would arguably delay the fix rather than help. Treating this as a minor nit consistent with the approval guidelines for bugs that don't warrant delaying merge.

[claude]

🟡 This auto-generated release PR adds a second ## [0.1.0] CHANGELOG section (dated 2026-07-31) that duplicates the pre-existing one (dated 2026-07-30) — both cite the identical commit 1b19a3b / PR #3236. The root cause is that a prior release PR (#3300) updated the CHANGELOG to 0.1.0 but never updated .release-please-manifest.json, which stayed at 0.0.1, so release-please believes 0.1.0 was never released and regenerates it here. Worth reconciling (drop the stale duplicate section) so 0.1.0 isn't documented twice under two different dates.

Extended reasoning...

What happened: packages/clickhouse/CHANGELOG.md now contains two ## [0.1.0] headers back-to-back — one added by this PR dated 2026-07-31 (lines 3-8) and a pre-existing one dated 2026-07-30 (lines 10-15, unchanged context). Both sections link the exact same compare range (clickhouse-migrator-v0.0.1...clickhouse-migrator-v0.1.0) and cite the exact same single commit 1b19a3b / PR #3236 under "Features". This is the same version documenting the same change twice, under two different release dates.

Root cause: git log shows commit 5088eee ("chore(main): release clickhouse-migrator 0.1.0", PR #3300) already added the 2026-07-30 section to the CHANGELOG. However, that prior release PR apparently didn't update (or a later fix reset) .release-please-manifest.json, which remained at "packages/clickhouse": "0.0.1" going into this PR. Because release-please's source of truth for "what's already been released" is the manifest, and the manifest still says 0.0.1, it concluded 0.1.0 had never shipped and regenerated a fresh 0.1.0 entry — hence the duplicate. This PR's manifest diff (0.0.1 → 0.1.0) confirms the jump skips any record of the version having been documented once already.

Why nothing upstream caught this: release-please computes the next version and changelog contents purely from the manifest + conventional commits since the last recorded release; it has no cross-check against the CHANGELOG.md file's actual contents, so a manifest/CHANGELOG desync like this (previously introduced by #3300) silently persists and resurfaces on the next release run rather than being detected/reconciled automatically.

Impact: This is confined to human-readable release documentation. No code path parses CHANGELOG.md for version comparisons — the manifest (which will be correct and singular at 0.1.0 after this PR merges) is what tooling actually relies on. So the practical effect is a confusing/duplicated changelog entry, not a functional or build break. It's worth cleaning up for clarity, but it doesn't block anything from working correctly.

Suggested fix: Before merging, drop the newly-added 2026-07-31 section (or merge its content into/replace the 2026-07-30 section) so packages/clickhouse/CHANGELOG.md has a single ## [0.1.0] entry. Since the manifest will already be correct (0.1.0) after this merges, no further desync should recur unless the CHANGELOG is manually edited out of sync with the manifest again.

Proof walkthrough:

1. Pre-PR state: manifest has "packages/clickhouse": "0.0.1", but CHANGELOG.md already has a ## [0.1.0] (2026-07-30) section (added in chore(main): release clickhouse-migrator 0.1.0 #3300) documenting commit 1b19a3b.
2. release-please runs, reads the manifest, sees 0.0.1 as the last released version for clickhouse.
3. It scans commits since the last manifest-recorded release, finds 1b19a3b (the same commit already changelogged), and computes the next version as 0.1.0 again.
4. It generates a new dated section (2026-07-31) for 0.1.0 and prepends it to CHANGELOG.md, right above the older 0.1.0 (2026-07-30) section — producing the duplicate visible in the diff.
5. It also bumps the manifest straight to 0.1.0, so after merge the manifest is correct going forward, but the CHANGELOG permanently retains both dated sections for the same version.