ci: prepare for 0.1.0 release to initiate intuit/auto releases automation

[yarikoptic]

Wire bids-utils into the intuit/auto release-on-PR-merge pipeline and document the workflow for maintainers + contributors. After this lands, v0.1.0 can be cut manually per RELEASING.md and every release from 0.1.1 onward is fully label-driven.

What's in this commit

• .autorc — replace the bare git-tag + conventional-commits config with the standard label-based pipeline used by citeproc-py and dandi-cli: git-tag, exec.afterRelease for PyPI publishing (python -m build && twine upload dist/*), and released for per-PR ship comments / labels. baseBranch: main, noVersionPrefix: false so tags read as v0.1.0 for hatch-vcs. Dropped conventional-commits — incompatible with the label-based bump workflow that the rest of the auto config now uses.

• .github/workflows/release.yml — adapted from citeproc-py: triggers on push: branches: [main] (post-merge) plus workflow_dispatch (manual ship); downloads the latest auto Linux binary at runtime so no node install is needed; runs auto shipit -vv --only-publish-with-release-label on auto-push so releases happen ONLY for PRs that carried the release label; uses secrets.GITHUB_TOKEN (default github-actions[bot]) — the simplest baseline. PyPI publishing via TWINE_PASSWORD=PYPI_TOKEN.

• CHANGELOG.md — initial file with a v0.1.0 entry in intuit/auto's prepend-friendly format (# v<version> (<date>) heading, emoji section headers, Authors: block, --- separator) so future releases prepend naturally. The 0.1.0 entry briefly summarises the shipped surface (commands, schema-driven migration, VCS integration, observability, integration-test fixtures) and flags pending work (Phase 2a/2b rename/edit-filename split, BIDS 2.0 migration, SC-003 perf verification).

• RELEASING.md — full release runbook: TL;DR for 0.1.1+ flow, manual workflow_dispatch path, complete copy-pasteable v0.1.0 cutover procedure (Steps 0–5 covering prerequisites, repo labels, PYPI_TOKEN secret, tag + build + upload + GH release + smoke test + workflow sanity-check), plus optional upgrade paths (protected-branch plugin, PR label enforcement à la dandi-cli, PyPI Trusted Publishing).

• CONTRIBUTING.md — new "Pull Requests and Release Labels" section explaining the label-based release flow for contributors: which bump label to pick (major/minor/patch), the auxiliary labels (release, internal, documentation, tests, dependencies, performance, released), and the aggregation rule for multi-PR releases. Points at RELEASING.md for the full procedure. (CLAUDE.md is a symlink to CONTRIBUTING.md, so both surfaces stay in sync.)

Steps to run AFTER this commit lands on main

1. Create release labels: GH_TOKEN=$(git config hub.oauthtoken) intuit-auto create-labels
2. Create the PYPI_TOKEN repo secret (project-scoped API token from https://pypi.org/manage/account/token/).
3. Cut v0.1.0 per RELEASING.md → "Cutting v0.1.0 — full runbook" (Steps 1–5).