Update CHANGELOG with 0.1.1.1 release notes

[lukstafi]

Summary

• Adds ## [0.1.1.1] -- 2025-07-18 section above the existing ## [0.1.0] section in CHANGELOG.md
• Documents removal of camlkit-base and ppx_sexp_conv dependencies
• Documents vendoring of camlkit-base.Runtime (with static config removed)
• Documents Runtime.Block fixes and addition of send_msg_suspended

Closes #2

Test plan

• Verify CHANGELOG.md has the ## [0.1.1.1] section above ## [0.1.0]
• Verify all four changes are documented (dependency removals, vendored Runtime, Runtime.Block fixes, send_msg_suspended)

🤖 Generated with Claude Code

[lukstafi]

What I'd Do Differently Next Time

Mistakes Made & Fixes

1. Read the proposal file first, before reading the task spec's Implementation Plan

What happened: The task spec included a short "Implementation Plan" snippet showing only a [0.1.1.1] template. I treated that as the full scope and implemented it without reading the proposal file at proposals/gh-ocaml-metal-2-update-changelog.md. The proposal clearly described three new sections (0.1.0.1, 0.1.1, 0.1.1.1) and was the authoritative source.

Next time: When a proposal: field appears in the task spec, read that file before writing any code. The Implementation Plan in the task spec is a summary; the proposal is the contract.

2. Verify release content with git log tag1..tag2 before writing CHANGELOG entries

What happened: I assigned vendored Runtime, camlkit-base removal, send_msg_suspended, and Runtime.Block fixes to 0.1.1.1 — because the GitHub release notes for 0.1.1.1 mentioned them. In reality those changes landed in 0.1.1; the 0.1.1.1 range only contains the ppx_sexp_conv removal.

Next time: For any CHANGELOG task, run git log tag1..tag2 --oneline for each inter-tag range before writing a single bullet. Never trust release notes alone to determine which version a change belongs to — GitHub release notes are sometimes written retroactively or cover multiple tags.

3. Audit all tags upfront

What happened: I focused on the tag named in the issue body (0.1.1.1) without first checking what other tags existed. Running git tag --list | sort -V at the start would have immediately revealed 0.1.0, 0.1.0.1, 0.1.1, 0.1.1.1 and prompted me to cover all gaps.

Next time: Start every CHANGELOG task with git tag --list | sort -V to map the full release landscape, then cross-reference with the existing CHANGELOG to find all undocumented ranges.

Suggested Process Checklist for CHANGELOG Tasks

1. git tag --list | sort -V — enumerate all tags
2. Read the proposal file (if present) for authoritative scope
3. For each undocumented range: git log tagN..tagN+1 --oneline --reverse
4. Write CHANGELOG entries from git history, not from issue/release-notes copy-paste
5. Double-check version assignments before committing