fix(halstead): Java true/false boolean literals not classified as operands

[dekobon]

Bug: Java true/false boolean literals not classified as Halstead operands

Summary

True (kind_id=8) and False (kind_id=9) exist in the Java grammar enum (src/languages/language_java.rs:8-9) but are not listed in the get_op_type operand match arm (src/getter.rs:557). Every other language with boolean literals correctly classifies them as operands. All boolean literals in Java are invisible to Halstead metrics.

Root Cause

src/getter.rs:556-559:

// Operands: variables, constants, literals
Identifier | NullLiteral | ClassLiteral | StringLiteral | CharacterLiteral
| HexIntegerLiteral | OctalIntegerLiteral | BinaryIntegerLiteral
| DecimalIntegerLiteral | HexFloatingPointLiteral | DecimalFloatingPointLiteral => {
    HalsteadType::Operand
},

True and False are absent. They fall through to _ => HalsteadType::Unknown.

Cross-language comparison

Language	True/False classified?	Location
Python	Yes	getter.rs:74
C++	Yes	getter.rs:504
JavaScript/Mozjs/TS/TSX	Yes	getter.rs:153 etc.
Rust	Yes (as BooleanLiteral)	getter.rs:424
Go	Yes	getter.rs:661
Kotlin	N/A (parsed as Identifier)	—
Perl	Yes	getter.rs:713
Java	No	getter.rs:557

Fix

Add True and False to the Java operand match arm in src/getter.rs:557:

Identifier | NullLiteral | ClassLiteral | True | False | StringLiteral | CharacterLiteral
| HexIntegerLiteral | OctalIntegerLiteral | BinaryIntegerLiteral
| DecimalIntegerLiteral | HexFloatingPointLiteral | DecimalFloatingPointLiteral => {
    HalsteadType::Operand
},

Key Files

File	Lines	Role
src/getter.rs	556-559	Java operand list — add True, False
src/languages/language_java.rs	8-9	Confirms True/False enum variants exist

Test

Update the Java Halstead test (src/metrics/halstead.rs:682-718) with code containing boolean literals and verify they appear as operands. Run cargo insta test --review.