Fix tool schemas degrading to {"type": "object"}

[CoronRing]

Closes #1458.

ParameterType.from_python_type is an identity lookup over 8 types with OBJECT as
the default. Anything it doesn't recognise silently becomes {"type": "object"}
which under from __future__ import annotations is everything. This PR also fix a major bug where, if any unrecognized class is resolved to an object, it cannot be corrected with a manual manifest.

Fixes

annotation	before	after
pattern: str under PEP 563	{"type": "object"}	{"type": "string"}
Literal["content", "files"]	{"type": "object"}	{"type": "string", "enum": [...]}
List[str] | None	{"anyOf": [{"type": "object"}]}	{"type": "array", "items": {"type": "string"}}
correct ToolManifest under PEP 563	NodeCreationError	accepted

Changes

• llm/tools/annotations.py (new): resolved_signature() evaluates string/ForwardRef
  annotations. Fast-paths to plain inspect.signature when nothing is deferred, so no
  behaviour change for normal code. Unresolvable names warn and pass through.
• llm/tools/parameter_handlers.py: UnionParameterHandler and
  SequenceParameterHandler now recurse through the handler chain so nested generics keep their structure.
• llm/tools/tool.py: two call-site swaps
• validation/node_creation/validation.py: resolve annotations before validating.
  Manifest type mismatches now warn instead of raising

For review

• One output change for code that already worked: Optional[str] was
  {"anyOf": [{"type": "string"}]}, now {"type": "string"}. Single-branch anyOf is
  noise to a provider and optionality already rides on required. Nothing in-repo
  depended on the old shape.
• _flatten_union_options is required, not cosmetic: UnionParameter.__init__ raises
  on a nested union, newly reachable now that union arms recurse (Union[Tuple[str, int], bool]).

[Amir-R25]

Thanks, good overall direction. A few edge cases and code styles need a little work.

A few were happening before but this PR is a good place to address.

I left a few comments:

• Nested forward references such as list["Payload"] are still not fully resolved.
• Tuple handling loses the tuple container and turns its element types into top-level union options.
• I also had a question about changing all manifest type mismatches from errors to warnings, rather than only relaxing validation when inference is unreliable.

One general readability note: there are quite a few inline comments that narrate what the next line is doing. I’d trim those and keep comments for non-obvious constraints or reasoning. A few comments also overstate the behaviour, for example, “get_type_hints()’s exact behaviour” and `“nested generics keep their structure” so simplifying them would make the implementation easier to review and maintain.

[Aryan-Railtown]

Amazing Work Guan!!
Just 1-2 minor things that i could find

[CoronRing]

Closing in favour of #1580.

Thanks @Amir-R25 and @Aryan-Railtown for the thorough reviews. Every round found a real edge case, and that is what convinced me this is the wrong shape for the fix.

The core of this PR is a hand-rolled annotation resolver (annotations.py) that evaluates strings and rebuilds generic aliases by hand. typing.get_type_hints(func, include_extras=True) already handles every case in the table above, including the nested list["Payload"] Amir found, and it follows Python's own annotation changes (3.14's annotationlib) without us maintaining a parallel implementation. The one thing the custom resolver bought was per-parameter tolerance when a single name can't be resolved, and a clear warning covers that well enough. On top of that the PR grew well past #1458: the tuple rework, recursive union/sequence handling and the Optional[str] output change are each their own change.

#1580 takes the stdlib route at a fraction of the size. I've left a review there with what it still needs, mainly the manifest escape hatch and a warning when resolution fails.

Where the rest goes:

• Nested unions (Optional[List[str]], Optional[Literal[...]] still degrading to anyOf: [object]): #
• required vs nullable semantics: Optional[X] with no default is reported as not required #1581
• Positional tuple items (prefixItems): Heterogeneous tuples do not constrain element position #1582
• The PEP 563 test module and the manifest / unresolvable-name cases in test_annotation_resolution.py are worth carrying over to fix(schema): resolve stringified type hints under PEP 563 for accurate tool schemas #1580 or the follow-up.