GeezerVison

Which issue does this PR close?

• No tracking issue. Companion to PR chore(release): prepare 0.1.0 release #89 on `branch-0.1`.

Rationale for this change

PR #89 lands the 0.1.0 changelog and version bump on `branch-0.1`. `main` needs two corresponding changes:

1. Carry the 0.1.0 changelog forward so it's discoverable from the default branch and future RMs can see prior release notes in one place rather than having to dig through release branches.
2. Bump the parent + module versions to `0.2.0-SNAPSHOT` so commits landing on `main` after 0.1.0 declare themselves as part of the next development cycle (and don't accidentally publish 0.1.0-SNAPSHOT artifacts that collide with the released 0.1.0 coordinates).

What changes are included in this PR?

• `dev/changelog/0.1.0.md` (new) — same file as in chore(release): prepare 0.1.0 release #89, generated by `dev/release/generate-changelog.py` (chore(release): add changelog generator script #88) over the full range from the root commit to the `branch-0.1` HEAD. Carried over verbatim.
• `pom.xml`, `core/pom.xml`, `examples/pom.xml` — version bumped from `0.1.0-SNAPSHOT` to `0.2.0-SNAPSHOT` (one line each — the parent declaration, with the two child modules inheriting via ``).

The native crate version in `native/Cargo.toml` stays at 0.1.0 for now. That crate is published in lockstep with the Java side and will be bumped together when work for the 0.2.0 line actually requires a new native version.

Are these changes tested?

`./mvnw -q validate` is clean: the parent and both children resolve to the new `0.2.0-SNAPSHOT` consistently.

Are there any user-facing changes?

`main`-built artifact coordinates change from `0.1.0-SNAPSHOT` to `0.2.0-SNAPSHOT`. This is the intended effect of starting the 0.2.0 development cycle. The 0.1.0 line continues to live on `branch-0.1` (PR #89).