chore(deps-dev): bump tree-sitter-language-pack from 1.16.1 to 1.16.2

[dependabot]

Superseded by #217, qualified at aee6879e38d7762b164c0c20cff54c6a4ce66240. The compatible language-pack update and Pi security repair are incorporated, preserving the Python 3.9 marker. Original branch history and review evidence remain preserved.

Bumps tree-sitter-language-pack from 1.16.1 to 1.16.2.

Release notes

Sourced from tree-sitter-language-pack's releases.

v1.16.2

Fixed

• process() returns a ProcessResult object again in Python, so attribute access works. In 1.16.1 the generator emitted options.ProcessResult as class ProcessResult(TypedDict, total=False), which is a type annotation and not a runtime class -- process() therefore handed back a plain dict, and every documented access (result.language, result.chunks, result.metrics.total_lines) raised AttributeError. Only Python was affected; the TypedDict path existed in no other binding, so the same call in Node, Go, Ruby or Java kept returning a real object throughout. ProcessResult is a @dataclass(frozen=True, slots=True) again, as it was before 1.16.1 and as every sibling binding already models it. (#183)
• The generated e2e suites assert against the shape their binding actually returns. Two backends were broken by one generator-level disagreement, in which the e2e emitter and the binding emitter held different ideas about the shape of a value they share. In Python, 72 of the 523 tests failed because the emitter wrote attribute assertions (result.language == "python") against a value the binding emitter was generating as a dict. In TypeScript, 18 of the 37 process tests failed because the emitter wrote String(e.kind).includes("Function") against kind, which is an object -- String({ type: "Function" }) is "[object Object]", so every structure-kind assertion evaluated false and reported it as the uninformative expected false to be true. Both emitters now read the value the way the binding presents it -- the dataclass attribute in Python, e.kind?.["type"] === "Function" in TypeScript -- and both suites are 523 passed / 0 failed. (#182)

Changed

• Regenerated all bindings, stubs, scaffolding, READMEs, test apps and e2e suites on alef 0.84.1 (from 0.82.2). 0.82.1 deleted the TypedDict path from the Python binding emitter and 0.75.0 fixed the e2e emitter, so this is the first release carrying both. 0.84.1 also makes generation reproducible across runs, which clears the 459 spurious TypeScript snippet-compile failures the 0.84.0 line reported.

Note on the npm package

@xberg-io/tree-sitter-language-pack skipped both 1.16.0 and 1.16.1 -- npm's latest is still 1.15.8 -- for two different reasons. 1.16.0 never got past Validate version consistency, the unrun task version:sync recorded in the 1.16.1 notes below. 1.16.1 cleared that gate and then failed E2E gate — Node on the 18 TypeScript failures above; that job blocks the npm publish, so the package never reached the registry. The wasm package is gated separately and did ship 1.16.1. 1.16.2 is the first release in which both gates pass.

Note

• 1.16.2 is a fix-only release. The two defects above landed together in 1.16.1 and are the whole content of this one; no grammar pins moved.

Changelog

Sourced from tree-sitter-language-pack's changelog.

[1.16.2] - 2026-09-05

Fixed

• process() returns a ProcessResult object again in Python, so attribute access works. In 1.16.1 the generator emitted options.ProcessResult as class ProcessResult(TypedDict, total=False), which is a type annotation and not a runtime class -- process() therefore handed back a plain dict, and every documented access (result.language, result.chunks, result.metrics.total_lines) raised AttributeError. Only Python was affected; the TypedDict path existed in no other binding, so the same call in Node, Go, Ruby or Java kept returning a real object throughout. ProcessResult is a @dataclass(frozen=True, slots=True) again, as it was before 1.16.1 and as every sibling binding already models it. (#183)
• The generated e2e suites assert against the shape their binding actually returns. Two backends were broken by one generator-level disagreement, in which the e2e emitter and the binding emitter held different ideas about the shape of a value they share. In Python, 72 of the 523 tests failed because the emitter wrote attribute assertions (result.language == "python") against a value the binding emitter was generating as a dict. In TypeScript, 18 of the 37 process tests failed because the emitter wrote String(e.kind).includes("Function") against kind, which is an object -- String({ type: "Function" }) is "[object Object]", so every structure-kind assertion evaluated false and reported it as the uninformative expected false to be true. Both emitters now read the value the way the binding presents it -- the dataclass attribute in Python, e.kind?.["type"] === "Function" in TypeScript -- and both suites are 523 passed / 0 failed. (#182)

Changed

• Regenerated all bindings, stubs, scaffolding, READMEs, test apps and e2e suites on alef 0.84.1 (from 0.82.2). 0.82.1 deleted the TypedDict path from the Python binding emitter and 0.75.0 fixed the e2e emitter, so this is the first release carrying both. 0.84.1 also makes generation reproducible across runs, which clears the 459 spurious TypeScript snippet-compile failures the 0.84.0 line reported.

Note on the npm package

@xberg-io/tree-sitter-language-pack skipped both 1.16.0 and 1.16.1 -- npm's latest is still 1.15.8 -- for two different reasons. 1.16.0 never got past Validate version consistency, the unrun task version:sync recorded in the 1.16.1 notes below. 1.16.1 cleared that gate and then failed E2E gate — Node on the 18 TypeScript failures above; that job blocks the npm publish, so the package never reached the registry. The wasm package is gated separately and did ship 1.16.1. 1.16.2 is the first release in which both gates pass.

Note

• 1.16.2 is a fix-only release. The two defects above landed together in 1.16.1 and are the whole content of this one; no grammar pins moved.

Commits

• a880285 chore(swift): update Package.swift with checksum for v1.16.2
• 4e4c695 chore(release): 1.16.2
• e92cb40 chore(alef): adopt 0.82.2 and regenerate
• 1996a20 chore(alef): regenerate the e2e C download script for 1.16.2
• 39ef8da chore(alef): regenerate the api and mcp skill bundles
• c280ad6 fix(docs): restore the blank rustdoc line above the Error heading
• 90b8d17 chore(plugin): re-pin the plugin bundles to 1.16.2
• e61b40a fix(ci): report the sanitizer finding instead of exiting on it
• d0886e8 fix(test-apps): restore the alef stamp on the C download script
• 9ec47f7 chore(release): 1.16.2
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.