Resolve nested method-call types through typed HIR

## Summary

AST-local `Expression::get_wave_type` panics for nested method calls and several other expression kinds. Type information needed after semantic analysis should come from typed HIR rather than being reconstructed from syntax and a local variable map.

## Related issues

- #407
- #409

## Relevant code

- `front/parser/src/ast.rs`
- typed HIR expression representation
- method-call semantic validation
- LLVM call and address lowering

## Scope

Ensure nested method-call chains receive resolved expression types in typed HIR and migrate their downstream consumers away from AST-local type inference. This issue is narrower than migrating the entire backend in #407.

## Acceptance criteria

- Chained and nested method calls type-check when every receiver and return type is valid.
- Invalid chains report the first failing member with a source span.
- Backend code consumes the resolved expression type rather than calling the panicking AST helper.
- Generic receiver and return types remain resolved after monomorphization.
- No valid nested method call triggers `nested method call type inference not supported yet`.
- Positive and negative tests cover fields, pointers/references where supported, generic receivers, and calls used inside larger expressions.

Start with front/parser/src/ast.rs and the typed HIR expression representation, then trace method-call semantic validation into LLVM call and address lowering. Verify how chained receivers and generic types are resolved after monomorphization. Done means valid nested calls type-check without the panic, invalid chains report the first failing member with a source span, and positive and negative tests cover the listed cases.

Written by the indexing model from the issue text.