docs: cut 0.1.0 changelog entry

[munkhorgil]

What

Moves the initial release notes from [Unreleased] to ## [0.1.0] in the changelog ahead of the first PyPI publish, and wires up the comparison links.

Why

roark-analytics-python-livekit 0.1.0 has not been published yet (no v0.1.0 tag). On squash-merge to main, the Release workflow detects the un-tagged version, runs the test matrix, and publishes to PyPI via Trusted Publishing, then tags v0.1.0 and cuts a GitHub release.

Prerequisite: a PyPI pending publisher must be registered for this repo (project roark-analytics-python-livekit, owner roarkhq, repo sdk-roark-analytics-python-livekit, workflow release.yml) before merge, otherwise the publish step will fail.

Checklist

• No secrets / no customer data
• No version bump (0.1.0 is the intended first release; only the changelog moved)

🤖 Generated with Claude Code

[claude]

Claude finished @munkhorgil's task in 44s —— View job

---

Code Review Complete

• Read changed files and gathered context
• Reviewed CHANGELOG.md changes
• Post comprehensive review summary

---

Code Review Summary

Category	Score	Notes
Code Quality	5/5	Minimal, correctly structured change
Security	5/5	Docs-only change; no secrets or sensitive info
Performance	5/5	N/A for changelog
Testing	5/5	N/A for changelog
Documentation	5/5	Comprehensive, well-structured release notes
Overall	5/5

Findings

No issues found. The change is exactly what it should be:

1. Section header is correct — ## [0.1.0] - 2026-06-04 follows Keep a Changelog format precisely, with the date matching today's release date.
2. [Unreleased] is now empty — standard practice; leaves a placeholder for the next unreleased cycle.
3. Comparison links are correct:
   • [Unreleased] → compare/v0.1.0...HEAD correctly points to changes after the tag once it exists.
   • [0.1.0] → releases/tag/v0.1.0 is the right target for a tag-based release.
4. Release notes content is comprehensive — covers all the public-facing features (observe_session, stereo recording, RoarkClient, ROARK_OBSERVABILITY_ENABLED, the examples project) without leaking any internal details.

One minor note

The [Unreleased] compare link will briefly return a 404 between merge and when the Release workflow creates the v0.1.0 tag. This is expected and unavoidable given the sequential nature of the release process — not a blocker.

Well done

The release notes strike a good balance: detailed enough to be genuinely useful (sample rates, chunk upload mechanism, kill switch behavior, aflush semantics) while staying entirely within the public API surface. Nothing in the notes leaks internal infrastructure or customer data.

Approved — ready to merge once the PyPI pending publisher prerequisite is confirmed.