…ing period

Recent changesets (`cjs-require-binding-tree-shake.md`, `public-path-fullhash-length-suffix.md`,
`html-entry-css-chunks-link-tags.md`, `align-html-lexer-script-data.md`, …) all
open with a capital letter and end with a period — that's what makes them read
as proper changelog entries when changesets is concatenated into the release
`CHANGELOG.md`. Document the rule explicitly and update the inline examples
("Fix split-chunks cache key collision.", "Add `module.generator.html.extract`
option.") so the guide matches the convention reviewers already enforce.

Also restyles the changeset added in the previous commit to match.

`module.buildInfo` is populated by `NormalModule#build` (and the equivalent
hook on other module types) before any code path that calls `updateHash`
runs — module hashing happens after the build phase. Cast straight to
`BuildInfo` and keep only the `.hash` check (the field itself is still
typed as optional on `KnownBuildInfo`). Matches what reviewers were
flagging on the prior commit.

…asset changes invalidate the HTML

`HtmlInlineStyleDependency.Template.apply` pulls the rendered CSS text
out of `codeGenerationResults` and substitutes it into the HTML — the
rendered text already has every `url(...)` rewritten to its hashed asset
filename by `CssUrlDependency`. The previous `updateHash` only folded
the CSS module's `buildInfo.hash`, which captures the CSS *source*. The
CSS source doesn't change when only the referenced asset's bytes change
— that change rides on `CssUrlDependency.updateHash`, which contributes
to the CSS module's *module* hash, not its `buildInfo.hash`. So the
HTML's `[contenthash]` stayed pinned even though the rendered HTML
embedded a new asset filename.

Recurse into the inline-CSS module's full `updateHash` so the same
asset-hash chain that already invalidates a standalone CSS chunk's
contenthash now also invalidates the host HTML's.

Adds `test/watchCases/long-term-caching/html-contenthash-inline-style-url/`,
which fails before the fix (HTML filename stayed `page.36e6bef5…html`
across the asset swap) and passes after.

…s are computed

`HtmlInlineScriptDependency` and `HtmlScriptSrcDependency` (the new
experimental HTML pipeline) used to call `compilation.getPath(chunk
filenameTemplate, …)` from their `Template#apply` — i.e. during
`Compilation#codeGeneration()`. That runs before `createHash()`, so
`chunk.hash` and `chunk.contentHash[type]` are still `null`. Any
`output.chunkFilename` (or `output.filename`) containing
`[contenthash]` / `[chunkhash]` / `[fullhash]` would throw "Path
variable [contenthash] not implemented in this context" from
`TemplatedPathPlugin`, breaking every HTML compile that wanted hashed
JS/CSS filenames. Even when the template happened to resolve, the
HTML module's own `[contenthash]` was computed from
placeholder-substituted bytes — so changing only an inline-script's
transitive dep flipped the embedded chunk URL but left the HTML's
`[contenthash]` pinned.

Defer the substitution instead: dep templates now emit a sentinel
(`__WEBPACK_HTML_CHUNK_URL__<hexChunkId>__<contentHashType>__END__`)
via `makeHtmlChunkUrlSentinel` from a new `lib/html/htmlChunkUrl.js`
helper, and `HtmlModulesPlugin#renderManifest` swaps every sentinel
for `${PUBLIC_PATH_AUTO}<chunkFilename>` *before* hashing the HTML
output — by that point `createHash()` has populated every chunk's
`chunk.contentHash[type]`/`chunk.hash`/`compilation.hash`, so the
chunk filenames' placeholders all resolve. Hashing the resolved
content (rather than the raw placeholder source) is what makes the
HTML's `[contenthash]` invalidate when a referenced chunk's filename
changes. `HtmlGenerator#_renderHtml`'s JS-export path resolves
sentinels inline too via the same helper; sentinels whose templates
can't be resolved yet (e.g. an unbuildable `[contenthash]` placeholder
at code-gen time) are left in place rather than thrown — `extract:
true` (the HTML output path) is the one that supports dynamic
filenames, and the JS export of the HTML string carries the
restriction that previously surfaced as a compile-time error.

Adds `test/watchCases/long-term-caching/html-contenthash-inline-script/`,
which fails before the fix (compile errors with `[contenthash]` in
`chunkFilename`) and after step 1 verifies the HTML invalidates when
the inline-script's transitive dep flips.

…dulesPlugin.computeContentHash

`renderManifest` hashed HTML bytes twice with identical boilerplate —
once for the `[contenthash]` substituted into `output.htmlFilename` and
once for the final asset cache key — each call re-implementing the
`createHash(hashFunction)` + `hashSalt` + `digest(hashDigest)` +
`nonNumericOnlyHash(_, hashDigestLength)` recipe. Pull both call sites
into a single static method on `HtmlModulesPlugin` so the recipe can't
drift between them, and so anyone reaching for "the HTML pipeline's
`[contenthash]` recipe" has a named entry point.

No behaviour change; the previously inlined `createHash` /
`nonNumericOnlyHash` requires are now inside the static method.

… static methods

`lib/html/htmlChunkUrl.js` was a single-file module exporting the
`makeHtmlChunkUrlSentinel` / `resolveHtmlChunkUrlSentinels` pair created
in the previous commit. Inline them onto `HtmlGenerator` as
`HtmlGenerator.makeChunkUrlSentinel` and `HtmlGenerator.resolveChunkUrlSentinels`
— that's the class responsible for emitting both sides of the
substitution (`_renderHtml` writes sentinels via dep templates and
resolves them on the JS-export path), so it's the natural home for the
sentinel format. `HtmlGenerator` doesn't import the HTML dependencies,
so the two dep templates (`HtmlInlineScriptDependency`,
`HtmlScriptSrcDependency`) can require it directly without introducing
a circular import. `HtmlModulesPlugin` already imports `HtmlGenerator`
and reaches the resolver through the same static method.

No behaviour change; just removes the standalone helper file.

…ntinel helpers

Both `HtmlGenerator.makeChunkUrlSentinel` (called from dep templates
during `Compilation#codeGeneration()`) and
`HtmlGenerator.resolveChunkUrlSentinels` (called from `_renderHtml`'s
JS-export path and from `HtmlModulesPlugin#renderManifest`) run after
`Compilation#seal`'s `optimizeChunkIds` hook, which is what
`chunkIds`/`NamedChunkIdsPlugin`/`DeterministicChunkIdsPlugin` use to
populate every chunk's `.id`. By the time these helpers run, every
chunk has a non-null id, so the defensive `chunk.id == null` branches
were dead code.

Adds a REQUIRED "Code comments" section to `AGENTS.md`: comments inside
`lib/`, `hot/`, `tooling/`, `test/` must be one or at most two short
lines and every line must add information not obvious from the code
(invariant, ordering constraint, pinned-bug workaround, higher-level
concept name). No multi-paragraph essays, no restating the next line,
no diff narration, no PR-body restatements, no task-framing quotes.
JSDoc on exported symbols is exempt because it's the type contract.

Also trims the verbose comments added in this branch (chunk-URL
sentinel docs on `HtmlGenerator`, the dep-template apply blocks, the
`HtmlInlineStyleDependency` / `HtmlSourceDependency` `updateHash`
explanations, `HtmlModulesPlugin.computeContentHash` JSDoc, and the
renderManifest "resolve before hashing" comment) to fit the rule —
105 lines removed, no behaviour change. Pre-existing comments in
other functions are left for their respective authors to revisit.