Scheduling client is absent from the unified Rust, Node.js, and Python facades

[jeremi]

What

registry-scheduling-client is a maintained product client, but none of the
three unified facades expose it:

• crates/registry-stack-client/Cargo.toml depends on the breg, casework,
  discovery, evidence, and relay clients only, and
  crates/registry-stack-client/src/lib.rs has modules for each of those with
  no scheduling module beside them.
• crates/registry-stack-client-node and crates/registry-stack-client-py
  mention scheduling nowhere.

An adopter who takes the unified client today cannot reach Scheduling through
it and has to depend on the product crate directly, which is the coupling the
facade exists to avoid.

Why it is filed rather than fixed

Purely additive and non-breaking, and #1092 is already large. Nothing in the
MVP is wrong without it; the facade is just incomplete.

Done when

• registry-stack-client gains a scheduling module re-exporting the client's
  public surface, matching how the sibling modules are written.
• The Node.js and Python facades carry the binding, with
  release/scripts/sync-registry-client-node.py --check passing.
• The facade's own tests and type checks cover the new surface.

Note

Adding the binding must not weaken the MVP dependency rule in AGENTS.md: no
scheduling crate may reach a BReg, Casework, or Evidence crate in either
direction. A facade that re-exports several products side by side does not
create such an edge, but the dependency-direction gate should be re-run to
confirm it.