fix(release): swap publish-ask / publish-crate ordering

[joaoh82]

Summary

The v0.2.0 release (Action run 25290833060) failed at `Publish sqlrite crate to crates.io`:

```
failed to select a version for the requirement `sqlrite-ask = "^0.2"`
candidate versions found which didn't match: 0.1.25, 0.1.24, ...
```

Root cause: the publish ordering reflected the pre-v0.1.19 dep direction (`sqlrite-ask → sqlrite-engine`) — but the v0.1.19 dep-direction-flip retrospective (roadmap.md L488) records that sqlrite-ask became pure-string-in/string-out and the engine took on the sqlrite-ask dependency (gated by the `ask` feature). Through 0.1.x this latent bug was masked because the engine's published version requirement was `^0.1` and old `sqlrite-ask 0.1.x` versions were already on crates.io. The v0.2.0 bump (`^0.2`) had no matching crate yet, so the publish failed loudly.

Fix

• `publish-ask` now runs first (depends only on `detect` + `tag-all`). No internal SQLRite path-deps after the dep-direction flip.
• `publish-crate` (engine) now waits on `publish-ask`. Comment updated to flag the latent bug + the retrospective.
• `publish-mcp`'s `needs: [..., publish-crate, publish-ask]` is unchanged — sqlrite-mcp still depends on the engine.

Resulting chain: `detect → tag-all → publish-ask → publish-crate → publish-mcp`.

Path forward for v0.2.0

After this merges, two options to finish the v0.2.0 cut:

Option	What	Tradeoff
A. Fire `workflow_dispatch` with `version=0.2.0`	Re-runs the whole release flow under the fixed ordering. The 3 Rust crate publishes succeed cleanly.	Already-shipped publishes (Python wheels, npm packages, Go SDK Release) re-run; PyPI/npm reject duplicate-version uploads, so those jobs fail noisily but don't undo anything.
B. Local `cargo publish`	From your machine: `cargo publish -p sqlrite-ask --no-verify && cargo publish -p sqlrite-engine --no-verify && cargo publish -p sqlrite-mcp --no-verify`. Manually upload the missing GitHub Release assets if needed.	Fastest path to "v0.2.0 fully shipped". Skips the workflow's GitHub Release creation steps for those three crates; you'd add the tags manually.
C. Cut v0.2.1	Ship a "release plumbing fix" v0.2.1 right after this merges. The fixed workflow runs cleanly end-to-end.	Wastes a version; pins users to v0.2.1 unnecessarily.

I'd recommend A — the duplicate-publish failures are noisy but harmless, and it keeps the release pipeline as the single source of truth for v0.2.0's ship state.

🤖 Generated with Claude Code