chore: update serde-saphyr to 1.0.1

[mwiebe]

What was the problem/requirement? (What/Why)

Update the workspace from serde-saphyr 0.0.29 to 1.0.1 while preserving
OpenJD's field-specific YAML validation behavior.

The 1.0 release rejects YAML non-finite float literals such as .nan, .inf,
and -.inf by default when deserializing into a dynamically typed value. OpenJD
first parses YAML into serde_json::Value, then performs typed model validation.
Rejecting these values during the first stage would replace OpenJD field paths
and model-specific diagnostics with a generic YAML decode error.

Review also identified two validation gaps:

• CLI YAML task parsing did not use strict boolean handling, so YAML 1.1
  shorthands such as yes, no, on, and off became booleans and were then
  rejected by the task-map decoder.
• Host requirement amount bounds could parse nan, inf, or infinity into a
  non-finite f64. This violated the finite-value invariant required by the
  resolved job model's equality, hashing, and serialization behavior.

What was the solution? (How)

• Updated the workspace dependency and lockfile to serde-saphyr 1.0.1.
• Set reject_non_finite_typeless_float: false when model documents and CLI
  YAML task files are parsed into serde_json::Value.
• Enabled strict boolean parsing for CLI YAML task files so shorthand boolean
  words remain strings. The parser retains serde-saphyr's default depth budget
  of 64; no weaker custom depth limit was added.
• Added structural validation requiring expression-free host requirement
  min/max values to be valid finite numbers.
• Added a second finite-value check after host requirement format strings are
  resolved during job creation.
• Added regression tests for YAML task boolean shorthands, literal non-finite
  bounds, invalid numeric literals, and format strings resolving to non-finite
  values.
• Updated the CLI parameter parsing, model validation, and job creation specs.

The host requirement checks align template acceptance and job creation with the
openjd-model-for-python v0 implementation: invalid or non-finite literals are
rejected during template validation, while dynamic format strings are accepted
as templates and checked after resolution.

The lockfile also reflects serde-saphyr's updated dependency graph, including
granit-parser 1.0.1 and removal of transitive packages that are no longer
needed.

What is the impact of this change?

The workspace now uses serde-saphyr 1.0.1 while retaining field-specific OpenJD
validation. Invalid and non-finite host requirement bounds can no longer enter
the resolved job model. YAML --tasks files treat yes, no, on, and off
as strings; explicit true and false remain booleans and are not valid task
parameter values.

Template parsing retains the existing 128-level OpenJD document depth limit.
CLI task parsing retains serde-saphyr's stricter default 64-level depth budget.

There are no public API changes.

How was this change tested?

• cargo fmt --all -- --check
• cargo clippy --all-features --all-targets --workspace -- -D warnings
• Focused model tests for literal and resolved non-finite amount values
• Focused CLI test for YAML boolean shorthand preservation
• cargo test --workspace --exclude openjd-sessions
• cargo test --workspace

The non-sessions workspace run passed. The unfiltered workspace run passed all
model, CLI, expression, JS, snapshots, and dependency-related tests. Two
unrelated Windows sessions tests failed because this development host returned
a domain-unavailable error (0x8007051F) for a nonexistent account where the
tests require ERROR_LOGON_FAILURE; the other 261 sessions integration tests
passed.

The exact Rust 1.94.1 MSRV check was not run locally because that toolchain is
not installed on this host.

• Have you run the unit tests? Yes, as described above.

Was this change documented?

Yes. The CLI parameter parsing, model validation, and job creation specifications
now document strict YAML task boolean handling and the two-stage finite amount
validation.

• Are relevant docstrings in the code base updated? No public docstrings were
  affected.

Is this a breaking change?

No. This is a validation bug fix. It rejects only invalid numeric amount bounds
that the Python v0 implementation rejects and that cannot safely be represented
in a resolved Rust job.

Does this change impact security?

No new security exposure is introduced. Both YAML entry points retain bounded
nesting, and the resolved model now rejects malformed non-finite amount values.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.