Release v1.1.0

[panyam]

What changes

Bumps package.json to 1.1.0 and writes the notes for it. Adds CHANGELOG.md and docs/releases/, neither of which existed before. No source changes, so nothing here affects the library at runtime.

Once this merges, v1.1.0 gets tagged on master and the GitHub Release goes up with docs/releases/v1.1.0.md as its body. npm publish is a separate manual step, since the release notes are worth reading before 1.1.0 becomes the version everyone resolves to.

Reviewer's guide

Release notes are read by two audiences with opposite needs, which is why there are two files rather than one. Someone upgrading wants the short answer: what broke, what got fixed, do I have to change anything. Someone three years from now bisecting a regression wants the long answer: which PR, which issue, what the actual mechanism was. A single file serves one of them badly. CHANGELOG.md is the index card, cumulative and scannable, one line per change with the issue and PR numbers. docs/releases/v1.1.0.md is the file behind the card, a paragraph per fix explaining the mechanism, and it doubles as the GitHub Release body so nobody has to keep two write-ups in sync by hand.

Read in this order:

1. docs/releases/v1.1.0.md, the one that gets read. Check the Upgrading section hardest, since that is the part people act on.
2. CHANGELOG.md, the index card. Worth confirming the issue and PR numbers line up with the long version.
3. package.json, one line.

Decision log

• Went with 1.1.0 rather than 1.0.10. Everything merged since v1.0.9 is a bug fix, so the patch reading is defensible. The minor is for the published package layout: lib/esm and lib/cjs now carry their own type markers, which changes how Node and every bundler classify those files. That reaches further than the bugs it fixes, and a patch release is the wrong place to put it.
• Did not back-fill CHANGELOG entries for v1.0.1 through v1.0.9. Those tags carry no notes, so any entry would be reconstructed from commit subjects and would read as more authoritative than it is. The file says so in its header.
• Put docs/releases/ outside docs/content/, which is the s3gen ContentRoot. Release notes are not doc-site pages and should not turn into one.
• Wrote the Known gaps section pointing at issues 19, 17 and 18 rather than leaving it out. Two of them are why examples on the docs site do not render, and someone reading the notes because they hit one of those is better served by a pointer than by silence.
• Left npm publish manual. There is no publish workflow and adding one is a separate decision about whether releases should be automated at all.

Risk / blast radius

• No source files change, so the library behaves identically to what CI already went green on for PR 24.
• The version number is the only thing here with reach. Once published, 1.1.0 is what npm install notations resolves to, and npm versions cannot be reused.
• Worth checking the Upgrading section for the // note. Documents containing // used to fail and now load, so a consumer that treated a parse failure as a signal will see behaviour change. Nothing that parsed cleanly before parses differently.

Before / after

$ npm view notations version
1.0.9                     # what npm serves today, with all three bugs

$ node -p "require('./package.json').version"
1.1.0                     # after this PR

Repository contents:

	before	after
CHANGELOG.md	absent	1.1.0 entry, header noting prior tags carry no notes
docs/releases/	absent	v1.1.0.md
tags with release notes	none of 9	v1.1.0 once tagged

Out of scope

• Publishing to npm, which is manual and follows the tag.
• A publish workflow, which is a separate decision from having CI at all.
• The 39 docs examples that do not parse. Being rewritten separately, with a ticket for the grammar questions they raise.