feat(types): add an optional invalid value hook

[MilesCranmer]

Why

Custom TypeSpec values need a way to construct an invalid result without adding a scalar constructor to the Julia type.

Scope

• Add optional TypeSpec(invalid="() -> value"), following the existing init callable convention.
• Generate DynamicExpressions.invalid_value(T) and validate that its result has type T and fails is_valid.
• Declare DynamicExpressions directly in pysr/juliapkg.json with its registry UUID. The docs Julia project does not load this backend and needs no extra dependency.

Tradeoffs

Dependent draft. Do not merge or release this PR yet.

This requires astroautomata/DynamicExpressions.jl#209 and a registered DynamicExpressions release containing that change. The latest real release is 2.10.1, which lacks invalid_value. The current ^2.10.1 constraint records the tested compatible series, but it does not enforce the new API. Before merge, replace that lower bound with the first actual registered release containing #209, then rerun ordinary resolver and CI tests. No future release number is invented here.

The Force example and its documentation mirror live in dependent docs PR #1350, not current master. Their scoped migration is to remove Force(u::Real) = Force(u,u,u) from sample, use sample="rng -> Force(randn(rng, 3)...)", and add invalid="() -> Force(NaN, NaN, NaN)". The matching prose must describe the invalid hook. Both revised definitions were compiled and compared locally; the complete example passed a small fit/predict smoke run. The existing dirty docs branch and definitions PR #1359 are untouched.

Blast Radius

Types without invalid states can omit this hook. Existing positional TypeSpec parameters retain their positions. Runtime hook loading does not invoke the constructor; validation does.

Verification

• Local Pkg.develop integration resolved this backend checkout, SymbolicRegression 2.4.0, and PythonCall 0.9.35. No local source overrides are committed.
• New invalid-hook and wrong-type/valid-result rejection tests passed through the actual Julia/Python runtime. The existing serial string fit/predict test also passed.
• Revised Force example fit 24 rows with 5 iterations and produced 8 finite three-component predictions without a scalar constructor. This smoke run does not claim scientific recovery accuracy.
• The revised script and docs Force definitions matched and compiled the invalid constructor.
• All scoped pre-commit hooks passed.
• An independent fresh resolver check confirmed released DynamicExpressions 2.10.1 lacks the hook, so release-backed tests remain blocked as described above.