Build httpfs against DuckDB v1.5.5

[fuziontech]

Why

Rebuilds the cred-refresh-write-retry patch set against v1.5.5 so a 1.5.5 worker row can be added to duckgres.

Without a 1.5.5 build of this extension the fleet cannot move off 1.5.3 — httpfs carries mid-statement S3 credential recovery on ExpiredToken, which is not optional in prod.

What

One line: .github/duckdb-version v1.5.3 → v1.5.5.

MainDistributionPipeline.yml's get-duckdb-version job reads that file and passes it to _extension_distribution.yml, so this is what selects the DuckDB the extension compiles against.

No source changes are expected — DuckLake made the identical 1.5.3 → 1.5.5 jump with zero source changes (clean build, 16083 assertions in 451 test cases). CI on this PR is what actually proves it for httpfs. If it goes red, the patch set needs forward-porting and that becomes the real work.

Why 1.5.5 specifically

v1.5.5 is the first release containing eaf8af373d, "Fix swapped min/max for multi-row-group 128-bit decimals in RETURN_STATS" — not in v1.5.3 or v1.5.4.

That matters beyond httpfs: DuckLake requests WRITTEN_FILE_STATISTICS and parses min/max straight into ducklake_file_column_stats, and those stats drive file pruning. On ≤1.5.4, a DECIMAL(p>=19) column in a multi-row-group file can therefore have wrong recorded bounds and prune away files that do contain matches — surfacing as silently missing rows rather than an error.

Next steps once this is green

1. Tag this branch v1.5.5-cred-refresh-write-retry → publishes httpfs-linux-{amd64,arm64}.duckdb_extension.
2. Merge Bump DuckDB submodule to v1.5.5 ducklake#33 and tag posthog/v1.5.5 → publishes the matching DuckLake build.
3. Add a 1.5.5 row (default: false) to both matrices in duckgres container-image-worker-cd.yml, canary, then flip the default.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Mntu6YhMuqNBFD9snXqvBR