feat: improve internal typings in manifest

[IzaakGough]

Summary

• Tighten the internal manifest typing so manifest spec generation no longer falls back to _typing.Any.
• Replace overly broad container types with explicit manifest value aliases and sequence/mapping handling that still accepts the runtime inputs the manifest code serializes today.

Problem/Root Cause

Issue #31 called out that the manifest internals still relied on _typing.Any, which left the manifest serialization path loosely typed even though it operates on a constrained set of values. The previous implementation used dict[str, _typing.Any], untyped helper inputs, and a narrow list check in _object_to_spec, so type information was lost across manifest parameter conversion and dataclass serialization.

Solution/Changes

This change introduces explicit aliases for supported manifest parameter types and manifest spec values, then threads those types through the manifest conversion helpers. The serialization path now distinguishes dataclass instances, mappings, and non-string sequences, which preserves support for inputs such as tuples while keeping the output normalized to manifest-compatible lists and dicts. It also updates the shared _params registry type so stored params are typed as Param or SecretParam instead of a generic Expression.

Testing

• Verified existing CI checks passed on the PR, including format, lint, docs, Analyze, CodeQL, and test (3.10) / test (3.12).

[gemini-code-assist]

Code Review

This pull request improves type safety in manifest.py by introducing strict type definitions (ManifestParamBase, SpecValue, etc.) and refactoring helper functions to use them. Two critical issues were identified in the review: first, using a generic alias (list[ManifestParamBase]) as a default_factory in ManifestStack will raise a runtime TypeError; second, the new strict type checking in _object_to_spec will raise a TypeError for previously supported types like tuple and custom mappings, which should be explicitly handled.