fix(ci): PR #296 blocked — duckdb crate version mismatch between Cargo.lock and Cargo.toml #298

Problem

PR #296 (cargo-minor-patch group with 17 updates) is failing CI because the duckdb crate version in Cargo.lock (1.10504.0) does not match the version pinned in backend/Cargo.toml (1.10500.0).

The CI step "Check spatial extension version sync" correctly catches this mismatch:

duckdb crate version mismatch: Cargo.lock=1.10504.0, manifest=1.10500.0

Context

The duckdb crate version is tightly coupled with the spatial extension binary version. The CI enforces that:

1. Cargo.lock duckdb version == Cargo.toml duckdb version
2. The spatial extension binary matches the duckdb core version

When Dependabot bumps the duckdb crate in the cargo-minor-patch group, it updates Cargo.lock but cannot automatically update Cargo.toml because the version is pinned exactly (= "1.10500.0" or similar).

Fix

For PR #296 specifically:

1. Update backend/Cargo.toml duckdb dependency to match the bumped version (1.10504.0)
2. Ensure the spatial extension manifest (backend/extensions/spatial-extension-manifest.json) references the correct duckdb core version
3. Download the matching spatial extension binary for the new version

Broader Issue

Every time the cargo-minor-patch group includes a duckdb bump, it will fail this CI check. Consider:

• Adding a Dependabot ignore rule for the duckdb crate in the minor-patch group
• Creating a separate, manually-managed workflow for duckdb upgrades
• Or automating the spatial extension manifest + binary update in CI

Affected PRs

• PR chore(deps): bump the cargo-minor-patch group across 1 directory with 17 updates #296: 17 cargo dependency updates blocked by this single mismatch
• PR fix(ci): PR #281 — duckdb 1.10503.1 breaks spatial extension loading (version mismatch) #283 (previous duckdb 1.10503.1 issue) was related

CI Run

https://github.com/sharkAndshark/mapflow/actions/runs/28342512744