catalog: ace-step v5 — defaults audit against upstream Gradio UI

asset_engine consumer audited the entire ace-step entry's defaults
and slider ranges against acestep/ui/components.py (althing thread
01KRCN0SHP9YJGQD58EE95DC5P). The catalog had been authored from
documentation rather than from source; ten defaults were wrong and
several slider ranges were either too narrow or impractically wide.

Defaults changed (catalog -> upstream-authoritative):
  infer_step                 20    -> 60
  guidance_scale             7.5   -> 15.0
  cfg_type                   cfg   -> apg
  omega_scale                0.5   -> 10.0
  guidance_interval          0.0   -> 0.5
  guidance_interval_decay    1.0   -> 0.0
  min_guidance_scale         1.0   -> 3.0
  use_erg_tag                false -> true
  use_erg_diffusion          false -> true
  actual_seeds               [42]  -> []   (random per call)

Slider ranges adopted from upstream where reasonable; bounded
locally where upstream's range is so wide it's unusable as a UI
slider:
  guidance_scale         [1.0, 15.0]   -> [0.0, 30.0]   (upstream)
  guidance_scale_text    [0.0, 15.0]   -> [0.0, 10.0]   (upstream)
  guidance_scale_lyric   [0.0, 15.0]   -> [0.0, 10.0]   (upstream)
  lora_weight            [0.0, 2.0]    -> [-3.0, 3.0]   (upstream)
  audio_duration         [5.0, 600.0]  -> [5.0, 240.0]  (upstream max)
  omega_scale            [0.0, 1.0]    -> [-10.0, 30.0] (UI bound; upstream is [-100, 100])
  min_guidance_scale     [0.0, 10.0]   -> [0.0, 20.0]   (UI bound; upstream is [0, 200])

Verified empty-string actual_seeds path against the live pipeline
source: pipeline_ace_step.py:set_seeds() falls through to
torch.randint when manual_seeds is "" (string, no comma, not all
digits). Smoked end-to-end: HTTP 200 in 11s, real WAV bytes back.

Reproducibility gap honestly documented in the entry's
reproducibility.notes and the actual_seeds field description: with
the new default `actual_seeds: []`, the wrapper rolls a random seed
inside the pipeline but doesn't capture or surface the chosen seed
back through the response. Default-defaulted assets cannot be
regenerated bit-exact; users requiring reproducibility must set
actual_seeds explicitly. Wrapper enhancement to surface the chosen
seed via X-Actual-Seeds header + a CatalogResponse.header_accessories
schema field is the planned fix.

ace-step bumped version 4 -> 5. catalog_version stays at 1 (no
schema changes).

Also added a "source-of-truth precedence" subsection to
CATALOG-CONTRACT.md's service-authoring notes, codifying the
read-order (Pydantic model > handler/pipeline code > Gradio UI >
README). Three ace-step bugs in three rounds (missing field, wrong
enums, stranded bytes, wrong defaults — really four) all share the
same root cause: catalog authored from doc surfaces that lie by
omission.

docs/asset-engine/CATALOG-CONTRACT.md

@@ -144,10 +144,23 @@ the consumer. This list is what we audit when planning a
 
 When **adding** a service to the catalog:
 
-- The Pydantic model in code is the ground truth for `fields:`. Read
-  the actual server code, not the README; READMEs rot. The
-  reproducibility audit at the bottom of `services.yaml` MUST get a
-  matching entry.
+- **Source-of-truth precedence.** OpenAPI is convenient but often lies
+  by omission (bare `string` types where the dispatch chain enforces
+  a specific enum, missing required-only-in-the-handler fields, etc).
+  The actual ground truth is, in order:
+    1. The Pydantic input model — for field shape, types, required-ness.
+    2. The handler / pipeline code — for enum dispatches and runtime
+       validation.
+    3. The Gradio UI / client code (when present) — for blessed
+       defaults and slider ranges, since the model authors picked
+       these for human-facing UX.
+    4. The README — least reliable; rots fastest.
+  Every catalog change should cite which of these was read. "OpenAPI
+  said X" is not enough on its own — past audits have caught three
+  bugs in a single service (ace-step) that all looked correct in
+  OpenAPI.
+- The reproducibility audit at the bottom of `services.yaml` MUST get
+  a matching entry for any new service.
 - If a service can't produce reproducible output (no seed AND
   non-deterministic model), that's a **bug in the service** — fix it
   there before adding to the catalog. The asset-engine relies on