Release 0.6.1

[Xophmeister]

Release 0.6.1

Description

Cutting a full release so we can move to Tree-sitter 0.25 and unblock downstream projects.

Also documented the new interim release process for configuration and queries.

Checklist

Checklist before merging, wherever relevant:

• CHANGELOG.md updated
• Documentation (The Topiary Book, README.md, etc.) up-to-date

• Updated regression tests

[Xophmeister]

@yannham This is the process we're suggesting for interim releases of the queries and/or configuration:

topiary/MAINTAINERS.md

Lines 157 to 193 in 9c5588c

	## Releasing new configuration and queries
	The `topiary-config` and `topiary-queries` packages may be released
	outside of full releases, to be reactive to changes to supported
	grammars and formatting queries, respectively. The process is not
	dissimilar from a usual release:
	1. Create a preparation branch from `main`. Unlike a full release,
	there's no need to freeze the [`CHANGELOG`]. However, the versions of
	`topiary-config` and/or `topiary-queries` will need to be updated in
	the root and their respective `Cargo.toml` files.
	The versioning scheme that has been chosen for these subpackages
	should be as follows:
	- `MAJOR.MINOR.PATCH`, matching those of `topiary-core`, when doing a
	full release. For example: `0.6.1`.
	- `MAJOR.MINOR.PATCH-YYYYMMDD`, when doing an interim release. That
	is, matching the `topiary-core` version, with the date appended.
	For example: `0.6.1-20250925`.
	There should be no need to update lockfiles, etc. so the above can
	simply be pushed to follow the usual approval-and-merge process.
	2. Do not tag the release, as this will trigger `dist` into cutting a
	full release. However, importantly, the new version of the respective
	subpackage(s) will need to be pushed to `crates.io`:
	```bash
	# Delete as appropriate
	cargo publish --package topiary-queries
	cargo publish --package topiary-config
	```
	As with a full release, publication to `crates.io` requires
	appropriate access.

Does that look good to you, for Nickel?

Follow-up question: Is this true?

There should be no need to update lockfiles

I don't remember if a version bump of workspace components affects Cargo.lock.

[Xophmeister]

#1009 should be merged into main and this branch rebased before merging.

#921 is really close to being ready. The functional pre- and post-processing code is now done, I just need to package it up and tidy-up some loose ends. I don't want this to delay the release, but if I can wrap it up quickly, it can be included 🤞

[Xophmeister]

I'm going to go ahead and release without #921; I don't want to rush it.