feat: expose unresolved call diagnostics and Rust coverage limits

[tob-scott-a]

The latest #73 comment reports thousands of unresolved Rust receivers and asks whether returned types connect subsequent calls. The parser records declared return types and nested call expressions, but does not propagate receiver types through expressions such as make().unwrap().execute(). This can disconnect a local implementation from reachability despite preserving its call site.

Add trailmark analyze --resolution, QueryEngine.call_resolution(), and unresolved_calls(name=None). The summary distinguishes extracted call sites from distinct proxy targets, counts affected callers, and groups unresolved calls by final syntactic callee label. Detailed rows retain per-call source locations and raw targets, including separate expressions that share an escaped proxy ID.

Document the reported standard-method, iterator, conversion, external-library, generated-builder, local-receiver, and enum-constructor patterns, with regression examples for all seven. The README explains that return-type metadata does not resolve later receivers and that opaque macro bodies and implicit calls are outside the report's denominator. The diagnostics do not claim whole-program coverage or add Rust type inference.

Normal graph JSON and summary output stay compatible. The new resolution report is an explicit output mode, mutually exclusive with summary and complexity output.

Validation: 1,421 pytest tests passed; Ruff lint/format and ty passed. Tests cover model classification, endpoint validation, counts versus target identities, caller filtering, per-site locations, CLI output, the seven Rust patterns, and incomplete reachability through returned values. Dependency setup used the checked-in lockfile with uv --frozen because the local global exclude-newer setting predates a required locked dependency.

Refs #73 (comment)