feat: Refine JS/TS binding entity classification for const/function/generator

[MattCozendey]

JS/TS binding declarations were not being classified with the right level of specificity.

Before this change:

• plain const bindings in JS/TS were flattened to variable
• function-valued bindings were only partially refined, and the behavior was not consistent across the TypeScript parser and the Rust core
• generator-valued bindings were not surfaced as a distinct entity type
• review risk detection only treated function and method deletions as function-like removals

After this change:

• const foo = "abc" is classified as constant
• let foo = "abc" and var foo = "abc" stay variable
• const foo = function () {} is classified as function
• const foo = () => {} is classified as function
• let foo = function* () {} is classified as generator
• function-like classification wins over declaration kind, so const does not mask a more specific function/generator entity type
• deleted generator entities are included in review risk signals the same way deleted functions already are

Implementation notes:

• added a small declaration classifier in the TS parser that first checks whether a binding's assigned value is function-like and only falls back to declaration kind (const vs let/var) when it is not
• mirrored the same logic in sem-core so the Rust path and TS path stay behaviorally aligned
• kept local non-function bindings inside function bodies suppressed, so this does not widen entity extraction noise
• added focused parser tests for both .ts and .js inputs covering constant, variable, function expression, arrow function, and generator cases

Repro before:

1. Create a file such as bindings.ts with:

   const constantValue = "abc"; let mutableValue = "def"; var legacyValue = "ghi";

   const functionExpr = function () { return 1; }; const arrowFn = () => 2; let generatorExpr = function* () { yield 3; };

2. Run the parser / semantic diff flow against that file.

3. Observe that:

   • constantValue is reported as variable instead of constant
   • function-valued declarations are not consistently classified between parser implementations
   • generator-valued declarations are not surfaced as generator

Expected behavior after this change:

• constantValue => constant
• mutableValue => variable
• legacyValue => variable
• functionExpr => function
• arrowFn => function
• generatorExpr => generator

Verification:

• added Vitest coverage for JS/TS binding classification
• added sem-core unit coverage for the same cases
• ran cargo test -p sem-core

[rs545837]

Thanks @Palanikannan1437 will check the JS/TS scenario and will revert back.

[Palanikannan1437]

Thanks so much @MattCozendey for the PR, here's some comments/questions/nitpicks....

[Palanikannan1437]

btw buildEntityId() bakes entityType into the ID, and the fuzzy matcher in identity.ts:109 requires same type too — so anything that flips from variable to constant/function/generator will show up as delete+add instead of modified. probably fine but worth knowing

[Palanikannan1437]

what happens with const a = 1, f = () => {};? this returns on the first matching declarator so the classification depends on ordering. pre-existing thing since we only emit one entity per declaration anyway but maybe worth a test to pin the behavior

[Palanikannan1437]

could we add async variants too? const f = async () => {} and const g = async function*() {} — just to make sure the stripping works e2e

[Palanikannan1437]

heads up — anyone with .semrc rules matching entityType: variable will quietly stop matching const declarations now. maybe a release note thing