fix(java): replace modified constructors when LLM adds new final fields

[misrasaurabh1]

Summary

When the LLM optimises a method by introducing a new final field (e.g. caching Arrays.hashCode in Expression.hashCode, or caching map.values() in LuaMap.valuesIterator), it also updates the class constructors to initialise that field. Previously codeflash:

1. ✅ Added the new field to the class
2. ✅ Replaced the target method
3. ❌ Did NOT update the constructors

This caused variable X might not have been initialized compilation errors.

Changes

parser.py

• JavaAnalyzer.find_constructors + _walk_tree_for_constructors + _extract_constructor_info: new methods to locate constructor_declaration nodes via tree-sitter
• JavaMethodNode.formal_parameters_text: captures the raw parameter list so constructors can be matched by signature

replacement.py

• ParsedOptimization.modified_constructors: new field to carry constructor sources that need replacing
• _parse_optimization_source: extract constructors from the same class as the target method
• _replace_constructors: new helper that replaces constructors by matching on formal parameter signature, preserving indentation
• replace_function: call _replace_constructors after the main method replacement

Test plan

• TestConstructorReplacement::test_constructor_updated_when_new_final_field_added — reproduces Expression.hashCode
• TestConstructorReplacement::test_constructor_updated_for_cached_collection_view — reproduces LuaMap.valuesIterator
• All 35 test_replacement.py tests pass

Fixes regressions from codeflash_all_3.log

• LuaMap.valuesIterator — variable valuesView might not have been initialized
• Expression.hashCode — variable cachedHash might not have been initialized
• Bin.hashCode — variable cachedHash might not have been initialized
• NettyTlsContext.createHandler — variable cipherSet might not have been initialized
• Pool.capacity — variable cachedCapacity might not have been initialized

🤖 Generated with Claude Code