Add dynamo.source and pin source revs to commits at submit

[ishandhanani]

Stacked on #399 (Track 2 of #385). Draft until the stack below it merges.

What

One shape for "this code, from git", shared by services[].source (#399) and the new dynamo.source:

dynamo:
  source:
    git: https://github.com/ai-dynamo/dynamo   # default when only rev is given, so forks are one line
    rev: refs/pull/14000/head                  # a commit, a tag such as v1.4.2, or a PR head

dynamo.source takes exactly one of git + rev (with optional patches, the old cargo_patches), pypi (the old version), or wheel. It maps onto the legacy DynamoConfig fields at load, so the install code and every downstream consumer keep reading hash / version / wheel unchanged and v1 recipes still load. Combining source with a legacy field is rejected.

Testing an unmerged Dynamo PR was not possible before: hash needed a commit SHA, and a plain clone does not carry PR refs. The cached source install now clones the configured repository and fetches a non-commit ref by name before checkout.

Pinning at submit

A ref like refs/pull/14000/head moves. srtctl apply resolves every unpinned source.rev (Dynamo and services alike) with git ls-remote, preferring the peeled commit for tags, and records it as source.sha in the submitted config.yaml. Comments are preserved and the recipe on disk is untouched. The job builds exactly the commit the lockfile names, and the /configs/dynamo-wheels cache is keyed by that commit, so two runs of one recipe cannot silently build different code because the PR was pushed to while the job sat in the queue.

• dry-run, preflight, and resolve-override never touch the network.
• A resolution failure warns and leaves the ref unpinned rather than blocking the submit; the compute node then fetches the ref by name and the cache keys on the sanitized ref.
• --json output lists what was pinned under pinned_sources; dry-run prints the Dynamo source and whether it is pinned.

Also

• examples/features/dynamo-source.yaml: Dynamo built from the v1.4.2 tag (the same release the PyPI examples install). --set dynamo.source.rev=refs/pull/<n>/head turns it into a PR test.
• Docs: ## dynamo in docs/config-reference.md, the pinning note in docs/services.md, regenerated docs/schema-reference.md.
• Tests: tests/test_source.py (shape validation, git ls-remote resolution incl. peeled tags and failures, pinning across plain and override-format documents with comments kept, the Dynamo mapping and install script for unpinned refs, pinned SHAs, forks, and patches, and the submit-path materialize_config_path behaviour) plus dry-run cases.

Validation

• Full suite green (1827 passed); lint, schema-docs drift check, every example validates.
• Live git ls-remote resolution of v1.4.2 and refs/pull/14000/head against ai-dynamo/dynamo from this branch.
• sa-b200, job 12007: srtctl apply pinned v1.4.2 to 2ecbdfdf and wrote the sha into the submitted config.yaml (--json listed it under pinned_sources); the workers did a cold source build at that commit inside the SGLang container (rustup, cargo, maturin), populated /configs/dynamo-wheels/2ecbdfdf..., and the aggregated Dynamo benchmark completed. Whole job, build included: 7m45s.
• sa-b200, job 12009: the same recipe resubmitted. The install reused the cached wheel for the pinned commit (no cargo or maturin output in the worker logs, straight to Dynamo installed from source (2ecbdfdf...)) and the benchmark completed. Whole job: 3m06s.

[ishandhanani]

Consolidated into #407, which carries these same commits as one PR against main (this description is reproduced there as one of its parts). Closing to keep review in one place; the branch stays for per-step reference via stack #398.