Add chunk-aware payload generation and a streaming send/receive path for
large rowsets and oversized BLOB/TEXT values, while keeping the existing
monolithic payload APIs fully compatible.

Payload generation:
- Add cloudsync_payload_chunks() as a SQLite virtual table and a
  PostgreSQL set-returning function, with optional since_db_version,
  filter_site_id, and until_db_version inputs; each chunk carries its
  index, size, row count, db version range, and a stable watermark.
- Add the persisted global setting payload_max_chunk_size (default 5 MB,
  clamped to a 256 KB minimum and a hard 32 MB ceiling); it controls
  generation only, never apply-time acceptance.
- Add v3 fragment payloads so a single oversized BLOB/TEXT value can span
  multiple chunks: receivers stage fragments in the
  cloudsync_payload_fragments table (created at init time), apply the
  value once complete, tolerate duplicate and out-of-order delivery, and
  clean up stale incomplete groups.
- Tag permanent payload-size errors with parseable error codes.

Network transport:
- Stream outgoing changes through cloudsync_payload_chunks() instead of
  building one monolithic payload; announce the chunk stream to /apply as
  an all-or-nothing batch (batchId/chunkIndex/isFinal) sent inline as
  blob or via upload URL, and advance the send checkpoint only after the
  whole stream succeeds.
- Support chunked /check responses via positional-cursor paging with
  inline payload support, a dynamic JSON token budget, and strict cursor
  handling (never advance the receive cursor on a non-final chunk, treat
  unparseable or cursor-less non-final responses as errors).
- Rename the receive entry point to cloudsync_network_receive_changes()
  with drain-all semantics and a configurable chunk cap; fail fast on
  non-retryable check failures.

Compatibility: cloudsync_payload_encode() remains supported, and
cloudsync_payload_apply() accepts legacy, monolithic, and v3 fragment
payloads regardless of the local chunk-size setting.

Also: PostgreSQL 1.0→1.1 migration script, PG memory-context and
PG_TRY/exception-stack fixes in the new SRFs, dblink in the Postgres
debug Docker images, per-branch beta Docker images on green pushes,
extensive SQLite unit / PostgreSQL SQL / chunked e2e integration
coverage, and API, performance, README, and changelog updates.

…nitialized (#54)

Querying the cloudsync_payload_chunks vtab on a database where cloudsync
was never initialized surfaced a bare "SQL logic error": the internal
statements over cloudsync_changes failed at step time and the error code
propagated out of xFilter without ever setting the outer vtab's zErrMsg.
The /check endpoint hit this on nodes not configured for cloudsync,
while cloudsync_payload_apply already reported an actionable message.

- guard xFilter with the same is-initialized check (and message) used by
  cloudsync_payload_apply
- propagate inner-statement error messages onto the vtab's zErrMsg
- stop ignoring step failures of the watermark MAX(db_version) query
- unit test: Payload Chunks Uninitialized
- e2e: Failure Path Test now asserts the forwarded "cloudsync is not
  initialized" message on send, receive (non-retryable SQL error), and
  sync; red against nodes still running 1.1.0, green once they run 1.1.1
- bump CLOUDSYNC_VERSION to 1.1.1 and add the CHANGELOG entry (no PG
  changes, extension version stays 1.1 — no migration needed)

…bles are missing (#55)

Querying cloudsync_changes (directly or via cloudsync_payload_blob_checked)
on a database whose cloudsync_table_settings rows survived while every
*_cloudsync meta table was lost — e.g. a dump/restore that skipped them —
returned SQLITE_NOMEM: the NULL from vtab_build_changes_sql fell through
the config-exists guard added in #54. SQLite Cloud reported it on the
/check path as "Not enough memory to execute query", pointing operators
at memory instead of the real state.

- xFilter now distinguishes this state (settings rows present, zero
  %_cloudsync tables in sqlite_master) and raises "cloudsync settings
  reference tables whose sync metadata is missing" with the re-init
  remediation; genuine OOM still returns SQLITE_NOMEM
- unit test: Changes Vtab Missing Meta Tables (red before, green after)
- bump CLOUDSYNC_VERSION to 1.1.2 and add the CHANGELOG entry (SQLite
  vtab only, no PG changes, extension version stays 1.1)

…istory (#57)

A fresh receiver's first check makes the server spool the ENTIRE tenant
history (which grows every run) and answer 202 while preparing; the spool
snapshot also predates the batch this test just sent. The capped loop's
80x1-chunk budget was therefore O(total history) and started failing
permanently once history outgrew it.

Catch the receiver up before sending the test batch: send a sentinel row
and drain (uncapped) until it arrives. A 202 yields rows=0/complete=1 —
indistinguishable from drained — so the sentinel's arrival is the only
reliable end-of-replay signal. The capped budgets are now O(this test's
batch). Sentinels are deleted in the tests' remote cleanup.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Add test_token_auth: mints a user token from the weblite gateway
(POST /v2/tokens, authenticated with INTEGRATION_TEST_APIKEY) via the
curl CLI, then runs the same sync roundtrip as test_init authenticated
with cloudsync_network_set_token instead of the apikey. Uses a fixed,
obviously-synthetic userId and a 24h expiry so repeated runs don't leave
live credentials behind. Skips when INTEGRATION_TEST_WEBLITE_ADDRESS is
not set; CI passes the new secret through env, docker and android legs.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

The android emulator images ship no curl binary, so minting the gateway
token via popen(curl) read an empty response and the test failed. Probe
for the curl CLI first and report SKIPPED when it is missing.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The repo default GITHUB_TOKEN is read-only, so the reusable changelog
workflow's requested permissions exceeded the caller's and every run
failed at startup. Scope the grant to the calling job.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Make the published sqlitecloud/sqlite-sync-supabase image build on both
Supabase base families - the Ubuntu-userland images and the newer
Alpine-userland ones - and publish the Alpine PG17 build behind explicit
:17-alpine tags.

Both bases run a Nix-built, glibc-linked PostgreSQL, so the same glibc
extension artifact is installed either way; only the build-time userland
tooling (apk vs apt-get) and the pg_config path differ.

- Dockerfile.supabase.release: detect the package manager, resolve
  pg_config from the Nix profiles the bases ship, and remove curl again
  only when it was not already part of the base image
- workflow: add the PG17 Alpine row (base 17.6.1.151) behind a tag_suffix
  so it cannot collide with the :17 alias, and smoke test every image
  (CREATE EXTENSION + cloudsync_version) on a booted amd64 container
  before the multi-arch push
- bump the PG15 base pin 15.8.1.085 -> 15.8.1.135. This crosses Ubuntu
  20.04 -> 24.04, which shifts the postgres UID 105:106 -> 101:102 and
  needs a one-time chown on existing deployments; documented in the
  quickstart and CHANGELOG

Validated: :17-alpine running in a full self-hosted Supabase stack on
amd64, and the :15 chown migration verified on a live deployment.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix: make local Supabase build-from-source work on Alpine bases (#60)

Compile the extension in a dedicated glibc builder stage (official
postgres:<major> image with PGDG headers, the same toolchain that builds
the release artifacts) instead of installing an apt toolchain into the
Supabase base, and resolve pg_config in the runtime stage by probing the
Nix profile paths instead of hardcoding the Ubuntu-only location. The
runtime stage no longer needs a compiler or package manager, so the
Ubuntu/Alpine userland difference stops mattering; both families run a
Nix-built, glibc-linked PostgreSQL, so the same .so serves both.

postgres-supabase-build derives the builder's PG major version from the
resolved base image tag, so auto-detection from a running Supabase CLI
stack picks matching headers for PG15 vs PG17.

Verified: CREATE EXTENSION cloudsync + cloudsync_version() on Alpine
17.6.1.151 and Ubuntu 17.6.1.071 / 15.8.1.135.

Closes #60

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: align .PHONY and postgres-help with actual smoke-test target names

The targets are postgres-supabase-run-test / postgres-docker-run-test,
but .PHONY and the help text advertised *-run-smoke-test, which does not
exist.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>