chore: bump version to 0.6.0

[giswqs]

Summary

• Bump version from 0.5.0 to 0.6.0 across the npm workspaces, the Tauri desktop crate, and the Python processing sidecar
• Update docs (README, architecture, index, project-format) to reference 0.6.0

Test plan

• pre-commit run --all-files passes (includes npm build)

[github-actions]

Netlify preview: https://pr-86--opengeos.netlify.app

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[github-actions]

The FastAPI version string is a second source of truth that will silently drift again in future bumps. Consider reading it from the installed package metadata instead:

Suggested change

	app = FastAPI(title="GeoLibre Server", version="0.6.0")
	app = FastAPI(title="GeoLibre Server", version=importlib.metadata.version("geolibre-server"))

You'd also need import importlib.metadata at the top of the file.

Unrelated but now stale: the module docstring on line 4 still says "Future integrations (v0.5+)" and the /run handler (line 56) still carries # TODO(v0.5). Both milestones have now been released and superseded; the planned GDAL/GeoPandas integrations are unimplemented but the marker version is in the past. At minimum the references should be bumped to v0.7+ or the TODOs replaced with a tracked issue link.

[github-actions]

The lockfile's embedded engines.node was bumped from >=18 to >=22 here, consistent with the current root package.json. However, the three CI workflows (release.yml:49, pages.yml:40, netlify-preview.yml:39) all use node-version: lts/* without a floor pin. lts/* resolves to whatever GitHub Actions considers the current LTS release; if it ever resolves to a version below 22 in a maintenance-LTS window, npm ci with engine-strict enabled would break the build silently. Pinning to node-version: '22' (or adding a .nvmrc) would eliminate the ambiguity.

[github-actions]

Code review

Bugs

Finding	File	Confidence
PROJECT_VERSION = "0.1.0" in packages/core/src/types.ts:40 was not updated by this version bump. This constant is written into every .geolibre.json file at createEmptyProject() (line 30) and projectFromStore() (line 89). Every project saved with the 0.6.0 release will still be stamped "version": "0.1.0", making it impossible for future migration logic to distinguish files created by any 0.x release. sample-data/example.geolibre.json likewise still carries "version": "0.1.0". If the constant is intentionally a schema version (decoupled from app version), it should be renamed PROJECT_FORMAT_VERSION and the design documented explicitly.	packages/core/src/types.ts:40	High

Quality / Maintainability

Finding	File	Confidence
FastAPI version= is a hardcoded literal that diverged from pyproject.toml (was 0.1.0 while pyproject was 0.5.0) and needed a non-sequential jump here. Using importlib.metadata.version("geolibre-server") would keep them in sync automatically. See inline comment.	backend/.../main.py:18	High
Module docstring says "Future integrations (v0.5+)" and /run carries # TODO(v0.5) — both milestone references are now past-due. v0.5 was released and superseded without delivering GDAL/GeoPandas/DuckDB Spatial. See inline comment.	backend/.../main.py:4,56	High
All three CI workflows (release.yml, pages.yml, netlify-preview.yml) use node-version: lts/* while package.json now requires >=22. The wildcard is unpinned; a maintenance-LTS window could resolve below 22 and break builds. See inline comment.	.github/workflows/*.yml	Medium
docs/project-format.md:9 still documents the version field as Format version (0.1.0). Internally consistent with PROJECT_VERSION not being bumped, but amplifies the ambiguity about whether the format version is intentionally decoupled from the app version.	docs/project-format.md:9	Low

CLAUDE.md

No CLAUDE.md found in the repository; no project-specific guidelines to check against.

---

Most actionable finding: PROJECT_VERSION = "0.1.0" in packages/core/src/types.ts — not touched by this PR, so all 0.6.0-era project files will be stamped with the wrong version. All other findings are quality/maintainability concerns.