follow-up: move @altinity/clickhouse-http into a dedicated Altinity repository

[BorisTyshkevich]

Follow-up to #630.

Depends on: #630 Phase 8 shipped

Goal

After #630 Phase 8 proves @altinity/clickhouse-http is independently buildable, packable, installable, importable, and typecheckable from its published package surface, move that package into a dedicated Altinity GitHub repository and switch SQL Browser from the local workspace dependency to a released semver dependency.

This issue is intentionally not part of /ship 630.

skills/ship/SKILL.md is explicitly scoped to altinity-sql-browser and requires each unit's branch/PR/review/merge to live in this repository. Creating and shipping a second repository therefore requires a cross-repository workflow or an explicit extension of /ship; do not hide that remote mutation inside #630 Phase 8.

Preconditions

#630 Phase 8 must already be recorded as shipped in #630's <!-- ship-log --> and must provide docs/clickhouse-http-repository-extraction.md containing the tested mechanical extraction procedure.

Before this issue starts, verify on origin/main:

• packages/clickhouse-http has no imports from root src/**;
• its package.json is publication-ready;
• package build/typecheck/tests pass independently;
• npm pack plus the isolated tarball consumer proof passes;
• SQL Browser imports only the package's public exports;
• the package README documents native Response/body ownership and caller-signal cancellation lifetime;
• the root architecture guards added by Epic: extract the Fetch-native ClickHouse client into a reusable package #630 Phase 8 are green.

If those conditions are not true, fix #630 Phase 8's contract in altinity-sql-browser first rather than compensating during repository extraction.

Target

Preferred repository/package naming unless an Altinity naming decision recorded before implementation says otherwise:

GitHub:  Altinity/clickhouse-http
npm:     @altinity/clickhouse-http

The new repository should be Apache-2.0 and browser/Fetch-first.

Migration steps

1. Create the target repository with the package source/history extracted according to Epic: extract the Fetch-native ClickHouse client into a reusable package #630 Phase 8's handoff document.
2. Preserve useful package-level commit history where practical (subtree/filter-repo or another reviewed history-preserving method); do not copy unrelated SQL Browser history/files.
3. Install repository-local CI for the package's standalone gates:
   • typecheck;
   • unit tests;
   • build;
   • package/tarball contents;
   • isolated ESM consumer;
   • isolated TypeScript consumer;
   • Chromium/WebKit Fetch cancellation/streaming contract tests moved from SQL Browser where package-owned.
4. Configure release/versioning without storing credentials in git.
5. Publish the first package version or otherwise make the reviewed release artifact available to SQL Browser.
6. In altinity-sql-browser, replace the workspace dependency with the exact released semver version and update the lockfile intentionally.
7. Keep SQL Browser integration tests that exercise the authenticated/application path; move only package-owned protocol/Fetch tests to the package repository.
8. Delete packages/clickhouse-http from SQL Browser only after the released dependency is installed and all root gates/e2e pass against it.
9. Reconcile docs/ARCHITECTURE.md, CLAUDE.md, .wiki, and CHANGELOG.md so the package is described as an external first-party dependency rather than a workspace package.
10. Keep ADR-0005 historical evidence intact; add only a concise reference to the completed extraction/repository move if needed.

Compatibility requirements

The external package release must preserve #630's final contract exactly:

• low-level native Response identity;
• non-2xx response resolution at low-level request;
• untouched successful body until an explicit consumer is chosen;
• exact SQL;
• opaque Authorization;
• original caller AbortSignal controls the real Fetch request and post-header response body;
• cancellation isolation;
• raw-byte safety;
• package-owned progress/error/late-frame mechanics;
• no package-owned auth refresh, lifecycle, retry, or operation registry.

Switching repository/package resolution must be the only architectural change in this issue.

Tests

New package repository

Run all standalone package gates created by #630 Phase 8 plus Chromium/WebKit Fetch/cancellation/streaming contract tests.

SQL Browser after released dependency cutover

Run:

npm ci
npm run check:types
npm run check:arch
npm run check:schemas
npm run check:examples
npm test
npm run build
npm run test:e2e
npm run test:clickhouse-http:browser

If #630 Phase 8 chooses a different final name for the first-party browser-contract script, use that recorded name.

Acceptance criteria

• A dedicated Altinity repository contains only the reusable package and its package-owned tests/docs/tooling.
• Package standalone CI is green.
• The released package version is immutable and identifiable by semver.
• SQL Browser consumes the released package through normal dependency resolution, not a workspace/path/git dependency.
• packages/clickhouse-http is removed from SQL Browser after cutover.
• SQL Browser retains integration/auth/application tests; package protocol tests live with the package.
• No behavior or ownership boundary from Epic: extract the Fetch-native ClickHouse client into a reusable package #630 changes during repository extraction.
• SQL Browser still builds one self-contained dist/sql.html.
• Both repositories' architecture/release documentation is current.

Non-goals

• Redesigning the package API during repository extraction.
• Adding new protocol features.
• Moving SQL Browser auth/application/product code into the package repository.
• Reopening the @clickhouse/client-web decision.
• Storing npm/GitHub credentials or secrets in either repository.

Execution note

Do not invoke the current repo-scoped /ship skill on this issue expecting it to create the second repository. Use a cross-repository shipping workflow, or first extend /ship under its own reviewed issue so cross-repo branch/PR/release proof is explicit.