chore(vale): accept upstream Vale 3.24.0

[github-actions]

Upstream Vale is ahead of the version this repository packages.

This updates .github/scripts/vale-manifest.json to the new upstream
version and replaces every platform's SHA256 with the digest from
upstream's vale_<version>_checksums.txt.

Reviewing this is the trust boundary. Merging it authorizes the
publish phase to download those exact archives and package them; a
download that does not match a digest here aborts the run and
publishes nothing. Check the digests against upstream's checksums file
for the release before approving.

Merging this triggers the publish phase, which stamps every platform
package <valeVersion>-<yyyymmddhhmmss> and publishes the set. That
publish is inert on its own: @taskless/cli pins exact versions, so
nothing reaches a consumer until that pin is deliberately bumped —
which is what vale-upgrade.yml proposes, separately, once this has
merged and published. Merging THIS changes nobody's install.

This pull request rolls: if upstream releases again before it merges,
the branch, title, and body are rewritten to the newer version rather
than a second pull request being opened. Push a commit to the branch
and that stops — the workflow will not force-push over a commit it did
not write.

---

Upstream release notes — 3.24.0

https://github.com/vale-cli/vale/releases/tag/v3.24.0

This release adds vale test, a test runner for your rules. A rule that matches nothing still loads, runs, and reports success. You only find out it's broken when it misses something. Now each rule can carry its own test cases: a short document, and the alerts linting it should produce.

extends: existence
message: "Consider removing '%s'."
tokens:
  - perhaps
tests:
  - name: flags a hedge
    input: Perhaps we should ship.
    want: |
      1:1:House.Hedging:Consider removing 'Perhaps'.

Running vale test lints each case and shows a diff when the output doesn't match. A case can pin the exact output (want), check for part of it (contains), or check that something is left alone (absent). It can run one rule on its own or go through your project's configuration, and it can read its input as another format or through a View. script rules are tested the same way. --coverage fails any rule that no case makes fire, and the exit codes are built for CI.

See Testing and the announcement post.

Changelog

• 2ee78171 fix: A rule whose tests don't parse fails vale test instead of vanishing
• 77da0b08 refactor: Typed errors, pattern errors at the token, and readable contexts
• 634b321c fix: Errors show the real exit code, honor --no-color, and point at the config
• db39c406 feat: BasedOnStyles = NONE, the spelled-out empty value
• bc8b91d8 perf: Don't parse a file no rule can run on
• c283a4dc feat: Conditional sections, [glob if expr]
• 08923bdf feat: vale test, and install a package's own dependencies for it
• 424f6e62 fix: Keep a fenced block skipped when both pre and code are in SkippedScopes
• 84deb6c3 fix: Keep non-breaking and narrow spaces beside inline markup
• 8cbda873 feat(code): parse C# comments with the C# grammar (#1196)
• 24f277bb test: add vale test cases