docs(changelog): merge three orphaned [Unreleased] sections into their releases

[adnaan]

scripts/release.sh refuses to run while more than one ## [Unreleased] heading exists — a guard added in #154. There were three, and they blocked the release.

They were all stale

The file is newest-first from v0.20.0. None of the three was the live section; each sat buried in history at v0.8.26, v0.8.19 and v0.8.18, directly beneath the release it described.

Each was the curated half of a release whose generated half already had a heading. v0.8.19 reads:

## [v0.8.19] - 2026-04-05
### Changes
- feat: add data-lvt-target for cross-element targeting in lvt-el: methods (#53) (89aa203)

## [Unreleased]
### Added
- `data-lvt-target` attribute for cross-element targeting — `lvt-el:` methods can now operate on a different element via `#id` or `closest:selector`

The same change, written twice, under two headings.

Why delete the heading rather than retitle it

I tried retitling first. It produces a second ## [v0.8.19] in the same file, which is worse than the problem — so the stray heading goes and the content lands under the version it always belonged to.

Nothing was moved, reworded or reattributed. Three heading lines deleted.

Attribution checked, not assumed

The orphan above [v0.8.18] predicts its content shipped in v0.8.19. git tag --contains on the commit that introduced data-lvt-target returns v0.8.19 as the earliest tag. The position rule and the tags agree.

The duplicate ## [v0.7.0] heading is pre-existing and left alone — it isn't [Unreleased], so it doesn't block anything.

Verification

grep -c '^## \[Unreleased\]' → 0, and no new duplicate version headings. The pre-commit hook ran lint, 824 jest tests and the browser build.

🤖 Generated with Claude Code

https://claude.ai/code/session_0166MK1arBYbVZq6wfm8EsQZ

[claude]

Reviewed the diff — it's a clean, low-risk change: 3 deletions, 0 additions, only touching CHANGELOG.md. No code/logic paths affected.

Looks correct:

• Each removed ## [Unreleased] heading sits directly beneath a versioned release heading whose "Changes" entry describes the same commit as the "Added" content that follows — dropping the heading correctly folds duplicate content into the release it belongs to rather than moving/rewording anything.
• Post-fix, grep -c '^## \[Unreleased\]' → 0 is fine here since release.sh's guard is "more than one," not "at least one" — presumably the script (re)creates the section on the next unreleased change.
• Leaving the pre-existing duplicate ## [v0.7.0] heading alone is reasonable since it's out of scope (doesn't block the Unreleased guard).

One gap worth closing before merge:
The "Attribution checked, not assumed" section only shows git tag --contains verification for the v0.8.19 case. The other two (v0.8.26, v0.8.18) are attributed purely by file position ("directly beneath the release it described") without the same explicit tag check shown. Given the whole PR rests on "position and tags agree," it'd be worth confirming (or showing) that git tag --contains was also run for those two commits, not just inferred from placement — cheap to verify and removes any doubt.

Nit (non-blocking): a couple of the hunks leave 4 consecutive blank lines where there used to be 3 blank lines + heading + 1 blank line. Purely cosmetic (renders the same in Markdown), not worth blocking on.