chore(main): release client-proxy 1.0.0

[e2b-release-please]

🤖 I have created a release beep boop

1.0.0 (2026-07-07)

Features

• Adding client-proxy and clickhouse to e2b-artifacts (#3210) (5686d88)

Bug Fixes

• local-dev: rename API_GRPC_ADDRESS to API_INTERNAL_GRPC_ADDRESS in local dev env (#2589) (6c0bcb1)
• push client-proxy, dashboard-api, and docker-reverse-proxy image… (#2953) (1d930ee)

---

This PR was generated with Release Please. See documentation.

[claude]

🟡 The CHANGELOG will contain two identical ## 1.0.0 (2026-07-07) blocks after merge — the newly added block duplicates the pre-existing block already present at HEAD (both have byte-identical Features and Bug Fixes entries). Root cause: PR #3211 merged the initial 1.0.0 CHANGELOG entry without bumping .release-please-manifest.json (it stayed at 0.0.0), so release-please generated another 1.0.0 release PR that layers a second block on top. Consider closing this PR or manually squashing the duplicate block before merging, and fixing the release-please workflow so the manifest omission does not recur.

Extended reasoning...

What the bug is

After this PR merges, packages/client-proxy/CHANGELOG.md will contain two byte-identical ## 1.0.0 (2026-07-07) sections stacked on top of each other. The diff prepends a new 1.0.0 block (with the same Features and Bug Fixes) above the 1.0.0 block that PR #3211 already wrote to the file. The resulting file has two identical release headers for the same version — a malformed changelog by any standard convention.

Step-by-step proof

1. Run git show 47b4fc7 -- packages/client-proxy/CHANGELOG.md (PR chore(main): release client-proxy 1.0.0 #3211, chore(main): release client-proxy 1.0.0). It shows the file being created with a single ## 1.0.0 (2026-07-07) block containing the same Features + Bug Fixes entries seen in this PR.
2. Read the base-branch packages/client-proxy/CHANGELOG.md — it already has that 1.0.0 block at lines 3–14 (approximately).
3. Read the diff in this PR: it inserts a new ## 1.0.0 (2026-07-07) header at line 8 followed by identical Features/Bug Fixes bullets, above (not replacing) the existing block.
4. The post-merge file (shown in the modified-files context above) confirms it: lines 3–14 and 16–27 are byte-for-byte identical ## 1.0.0 (2026-07-07) sections.

Why release-please did this

Look at .release-please-manifest.json at the base of this PR: packages/client-proxy is still pinned to 0.0.0, even though PR #3211 already released 1.0.0. PR #3211's diff only touched the CHANGELOG — it did not update the manifest. Because the manifest is release-please's source of truth for "what version have I released," release-please believes 1.0.0 has not shipped yet and generates another 1.0.0 release PR. That PR's job is to (a) bump the manifest 0.0.0 → 1.0.0 (correct) and (b) prepend a new 1.0.0 CHANGELOG block (incorrect — one already exists).

Impact

Documentation-only. Runtime behavior of client-proxy, packaging, tagging, and container publishing are unaffected. The visible artifact is a malformed CHANGELOG that human readers will find confusing — two identical headers for the same date + version, back to back.

Fix

Two options, either resolves the immediate merge problem:

1. Close this PR. PR chore(main): release client-proxy 1.0.0 #3211 already released 1.0.0. Then manually update .release-please-manifest.json on main to set packages/client-proxy: "1.0.0" so release-please stops proposing this release. This is the cleanest path since the release already happened.
2. Squash the duplicate block before merging. Edit packages/client-proxy/CHANGELOG.md in this PR to delete one of the two identical 1.0.0 blocks, then merge. The manifest bump 0.0.0 → 1.0.0 is still correct and will prevent future duplicate PRs.

Either way, worth investigating why PR #3211 merged with a CHANGELOG update but no manifest update — that is the underlying process gap that produced this duplicate release PR.