Drop two wrapped-function matchers that no pinned grammar can produce

[kridaydave]

Two of the seven entries in JS_TS_WRAPPED_FUNCTIONS can never match a node in any grammar this repo pins. They are dead configuration that reads as live.

field_definition with name_field: "name" is unreachable because tree-sitter-javascript 0.23.1 declares that node with fields decorator, property and value only. child_by_field_name("name") returns None, so collect hits the else { continue } at src/engine/mod.rs:944 and moves on. The live entry for that grammar is the adjacent field_definition with name_field: "property".

property_definition is unreachable in all three grammars that share this table. It is absent from tree-sitter-javascript 0.23.1, from tree-sitter-typescript 0.23.2, and from its tsx grammar, so node.kind() never compares equal. Live coverage comes from public_field_definition with name_field: "name".

Verified against each vendored crate rather than from memory. Both node-types.json files and both parser.c symbol tables were read directly.

crate	node	present
tree-sitter-javascript 0.23.1	field_definition	yes, fields decorator/property/value
tree-sitter-javascript 0.23.1	property_definition	no
tree-sitter-javascript 0.23.1	public_field_definition	no
tree-sitter-typescript 0.23.2 (typescript)	field_definition	no
tree-sitter-typescript 0.23.2 (typescript)	property_definition	no
tree-sitter-typescript 0.23.2 (typescript)	public_field_definition	yes, fields decorator/name/type/value
tree-sitter-typescript 0.23.2 (tsx)	property_definition	no
tree-sitter-typescript 0.23.2 (tsx)	public_field_definition	yes

No behavior change. Removing an entry that never matched leaves the matched set identical, so the live wrapped-function coverage is untouched. The existing test at tests/engine_test.rs:864 asserts both calculateScore (variable_declarator) and handle (public_field_definition) are still extracted, so CI proves the survivors still fire.

This table is deliberately uniform and the two survivors look interchangeable with the deleted pair, so the next person adding a TypeScript class-field matcher had no way to tell which entries were live.

 src/engine/language.rs | 22 ----------------------
 1 file changed, 22 deletions(-)

Not shipped

Noted while reading, no code changed. Each needs a decision that is not a dead-code deletion.

• src/store.rs:830-836. capture_tag_meta panics on a crafted tag. open and close come from two independent find calls with no open < close check, so a tagger line whose name contains > slices out of order. Reproduced standalone with the exact expressions: byte range starts at 7 but ends at 5, exit 101. Reaching it needs a source repo carrying a loose annotated-tag object, which is a real guard question rather than a cleanup.
• src/store.rs:592-596. assemble_tree joins mktree rows with \n and no -z, so a filename containing a newline injects extra tree rows. Confirmed against git: one row for x\n100644 blob <sha>\ty produced a two-entry tree. The sibling writer strip_tree at src/store.rs:1870 already uses -z. Fixing this one is a behavior change to a write path.
• src/engine/mod.rs:143-150 and src/engine/mod.rs:502-506. Removed-function disputes hardcode row 0 and discard old_def.row, which is in scope. Every removal reports src/lib.rs:0.
• src/main.rs:278-281. adjudicate without --visibility uses VisibilityPolicy::default() instead of the ./visibility.toml discovery every other entry point uses, so an embargo_until in the project file is ignored and the verdict comes back Adjudicated.

Verification here is the grammar tables quoted above plus cargo fmt --all -- --check. The full gate is CI's to run.