to use for releasing new versions

**Target branch**: `release-0.8.x`

### What

Remove `\s*` from the `parseInstruction` regex in `lib/sax.js` so that
trailing whitespace inside a processing instruction is preserved instead
of silently stripped.

### Why

Per [XML spec §2.6](https://www.w3.org/TR/xml/#sec-pi), PI data is
everything between the mandatory separator whitespace after the target
and the closing `?>`. Trailing whitespace inside the PI boundary is
content — there is no rule to strip it. Conforming parsers (sax-js,
libexpat) preserve it.

This was already fixed on `master`/`0.9.x` as a side-effect of the large
DOCTYPE rewrite in PR #498 (22k lines). This PR is the minimal,
non-breaking backport for the maintained `0.8.x` line.

### How

`parseInstruction` builds a substring that already excludes `?>`, so `$`
anchors immediately before it. The `\s*` before `$` was greedily
consuming any trailing whitespace from PI data before passing it to
`domBuilder.processingInstruction`. Removing it — while keeping `*?` on
the data group to minimise diff — is the complete fix.

```js
// before
source.substring(start, end).match(/^<\?(\S*)\s*([\s\S]*?)\s*$/)
// after
source.substring(start, end).match(/^<\?(\S*)\s*([\s\S]*?)$/)
```

Five existing snapshots in
`test/xmltest/__snapshots__/not-wf.test.js.snap` were updated: they
captured the old buggy behaviour (trailing space stripped from
XML-declaration-like PIs in the not-well-formed corpus). The updated
snapshots reflect the now-correct output.

### Scope

Addresses the trailing-whitespace sub-issue from #42, backporting #498
behaviour to 0.8.x.

Add `.github/workflows/ci-local.sh` for running the full CI suite
locally before pushing. Exports `CI=true`, validates the active Node
version against `.nvmrc`, and runs the same steps as GitHub Actions.

Also adds the `format:check` npm script used by the CI script.

… (#968)

Fixes GHSA-wh4c-j3r5-mjhp — XML injection via unsafe CDATA
serialization.

### Fixed

- Security: `createCDATASection` now throws `InvalidCharacterError` when
`data` contains `"]]>"`, as required by the [WHATWG DOM
spec](https://dom.spec.whatwg.org/#dom-document-createcdatasection).
[`GHSA-wh4c-j3r5-mjhp`](GHSA-wh4c-j3r5-mjhp)
- Security: `XMLSerializer` now splits CDATASection nodes whose data
contains `"]]>"` into adjacent CDATA sections at serialization time,
preventing XML injection via mutation methods (`appendData`,
`replaceData`, `.data =`, `.textContent =`).
[`GHSA-wh4c-j3r5-mjhp`](GHSA-wh4c-j3r5-mjhp)

Code that passes a string containing `"]]>"` to `createCDATASection` and
relied on the previously unsafe behavior will now receive
`InvalidCharacterError`. Use a mutation method such as `appendData` if
you intentionally need `"]]>"` in a CDATASection node's data.