changie importer: convert a .changie.yaml project to trellis's layout

[tylerbutler]

Split out of #38, which delivered trellis init (the bootstrap half) and
deferred this.

Problem

Trellis is implicitly asking people to migrate off changie — DESIGN.md §7
records that trellis was a changie wrapper before the native engine replaced
it, and this repository still dogfoods changie for its own changelog. For a
project already on changie, adopting trellis's changelog engine today means
hand-converting every pending fragment and re-deriving the kind/bump table.

That is a chore, and it is exactly the kind of chore the tool exists to delete.

Proposal

An importer that reads a .changie.yaml project and writes the equivalent
trellis configuration and fragments. Two halves:

Configuration. .changie.yaml's kinds map onto
[tools.trellis.changelog] kinds — but changie's auto levels and trellis's
bump are not quite the same vocabulary, and changie's versionFormat /
kindFormat / changeFormat are Go templates where trellis uses minijinja.
The template translation is the part that needs design: mechanical for the
common formats, and probably better refused than half-translated for anything
custom.

Fragments. Existing .changes/unreleased/*.yaml become trellis's TOML
fragments (project, kind, body). Changie's project mode already carries a
project per fragment, so the mapping is direct; the naming scheme is not
(<project>-<n>.toml).

Batched version sections under .changes/ are the interesting question — they
are already rendered Markdown, so they may be better left alone and picked up
by trellis's existing changelog adoption
than re-derived.

Open questions

• trellis init --from changie, or its own trellis changelog import? init
  is about the workspace root; this is about the changelog engine, so the
  latter may fit better now that they are separate commands.
• Refuse or warn on a .changie.yaml using features trellis has no equivalent
  for (custom choices, post blocks, replacements)?
• Is a dry-run mode worth it, or does "it's all in git" cover it?

Notes

Sizeable enough to want its own design pass — it touches the changelog engine,
not just config generation, which is why #38 shipped without it.

[tylerbutler]

Confirmed post-1.0. The importer is additive — a new subcommand constrains no 1.0 promise — and the Go-template→minijinja translation flagged above wants its own design pass, which is why #38 shipped without it.

Separately: this repo continuing to use changie for its own changelog is not being treated as a 1.0 blocker. The release pipeline is wired to it, and switching mid-1.0-push risks the release process itself.