chore: regenerate THIRD-PARTY-LICENSES.txt

[leongdl]

What

Regenerates THIRD-PARTY-LICENSES.txt with scripts/check_third_party_licenses.sh --update.
Generated file only, 282 added lines, nothing removed.

Why

The THIRD-PARTY-LICENSES check job fails on mainline as it stands, so it fails on every
open PR. I hit it on #332, confirmed it is not that branch's doing, and it reproduces on a
clean mainline checkout:

$ git worktree add /tmp/tpl-mainline upstream/mainline
$ cd /tmp/tpl-mainline && scripts/check_third_party_licenses.sh
THIRD-PARTY-LICENSES.txt is out of date with respect to:
  * pyproject.toml [project.dependencies]
  * Cargo.lock (workspace)

No dependency changed. cargo-about did. The workflow installs it unpinned:

run: cargo install cargo-about --locked --features cli

which resolves to 0.9.2 today, and 0.9.2 emits every license file a crate ships rather than
one per crate. Two multi-licensed crates gained a second block:

Crate	Added
wasi 0.11.1+wasi-snapshot-preview1	Apache-2.0 with LLVM exceptions, alongside the existing block
encoding_rs 0.8.35	The BSD-3-Clause notice covering the WHATWG GB18030 index data

Both were already listed at these versions; the content is what grew. Nothing was removed, so
this adds license text we were previously under-reporting.

Root cause worth a follow-up

Pinning cargo-about in the workflow would make this reproducible instead of
time-dependent. As written, any future cargo-about release can turn this check red on
unrelated PRs, which is what happened here. I left it out of this change to keep the fix
mechanical and quick to merge — happy to send it separately if you want it.

Testing

$ scripts/check_third_party_licenses.sh
THIRD-PARTY-LICENSES.txt is up to date.

Run with cargo-about 0.9.2, matching what CI installs today.

[github-actions]

This new encoding_rs block is not a license — it is a chunk of Rust source code from the crate (gb18030_2022.rs: the GB18030_2022_OVERRIDE_PUA / GB18030_2022_OVERRIDE_BYTES tables), with the BSD-3-Clause header appearing as // comments rather than plain text.

This looks like a cargo-about license-file misdetection rather than an intentional attribution. Evidence:

• encoding_rs 0.8.35 is unchanged from the base commit, yet this is a brand-new stanza — the crate now appears three times in the file (line 611 in the Apache-2.0 group, this block at 2640, and the real BSD-3-Clause text at 2698).
• Line 2698 already carries the same BSD-3-Clause text in proper (uncommented) form, so this block adds no attribution coverage.
• Embedding ~40 lines of the dependency's implementation into a legal-attribution artifact is misleading to anyone auditing it, and it will silently churn on every future regeneration.

Suggest excluding this file from cargo-about detection (e.g. a [encoding_rs] clarification / ignore entry in about.toml) and regenerating, so encoding_rs resolves to just the Apache-2.0 and BSD-3-Clause stanzas.

[github-actions]

This PR touches only THIRD-PARTY-LICENSES.txt — Cargo.lock, about.toml, and about.hbs are all unchanged. So neither of the two new stanzas is explained by a dependency change:

• wasi 0.11.1 is still also listed in the plain Apache-2.0 group (line 2120), so it now appears twice under two mutually-exclusive license selections, and the ~225-line Apache-2.0 body is duplicated verbatim just to append the LLVM exception.
• encoding_rs 0.8.35 gained a stanza containing crate source code (see the other comment).

Both point at a change in the generator rather than the dependency graph. Worth noting in the commit message / PR body which cargo-about version produced this output, and confirming the regeneration is reproducible — otherwise this file will churn unpredictably on each run and reviewers have no way to tell an intentional attribution change from a tool regression.