fix(api-catalog): distinguish $defs keys for same-file property refs [DEVEX-965]

[jpage-godaddy]

Summary

• derive_defs_key_for_path derived a $defs key from a $ref target's bare file stem, ignoring any #/properties/<name> fragment. Refs into different properties of the same model file (e.g. FulfillmentPlan.yaml#/properties/storeId vs #/properties/orderId) collapsed onto one $defs key, so listFulfillments' storeId path parameter resolved to the wrong (order-reference) schema.
• Fold the #/properties/<name> path into the derived key when present, so distinct properties from the same file get distinct keys (e.g. FulfillmentPlan_storeId, FulfillmentPlan_orderId). Each path segment has its literal _ doubled before joining, so a property literally named e.g. a_b can't collide with nested a/b segments (refined during review).
• Regenerated the catalog (cargo run -p generate-api-catalog); only fulfillments.json, orders.json, and manifest.json were affected — the only domains with property-fragment refs into a shared file.

Fixes DEVEX-965.

Test plan

• Added unit tests for the new key-derivation behavior (simple, nested, and underscore-collision #/properties/ fragments)
• cargo check / cargo clippy -- -D warnings / cargo fmt --check clean across the workspace
• cargo test --workspace passes (452 tests)
• Verified regenerated fulfillments.json: listFulfillments's storeId param now resolves to FulfillmentPlan_storeId ("ID of the store...") instead of the order-reference schema; orderId and fulfillmentId similarly split into correct, distinct keys

[Copilot]

Pull request overview

Fixes API-catalog $defs key derivation so $refs that target different #/properties/<name> fragments within the same model file no longer collapse onto a single key, preventing incorrect schema resolution in generated domain catalogs (DEVEX-965).

Changes:

• Updated derive_defs_key_for_path to fold #/properties/... fragments into the derived $defs key (in addition to existing component-schema fragment handling).
• Added unit tests covering simple and nested #/properties/ fragment key derivation.
• Regenerated the API catalog outputs, updating orders.json, fulfillments.json, and manifest.json.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
rust/tools/generate-api-catalog/src/main.rs	Adjusts $defs key derivation to incorporate #/properties/... fragments and adds tests for the new behavior.
rust/schemas/api/orders.json	Regenerated catalog output reflecting distinct per-property $defs keys for property-fragment refs.
rust/schemas/api/fulfillments.json	Regenerated catalog output splitting previously-colliding property-fragment refs into distinct $defs keys.
rust/schemas/api/manifest.json	Regenerated manifest timestamp and domain listing output.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

rust/schemas/api/manifest.json:8

• The regeneration changed the ordering of entries under domains, which makes manifest.json diffs noisy. This is likely because CatalogManifest.domains is a HashMap (rust/tools/generate-api-catalog/src/main.rs:134-137), so serialization order isn’t stable across runs. Consider switching to an ordered map (e.g., BTreeMap/IndexMap) or sorting keys before writing manifest.json, then regenerate so future runs are deterministic.

  "domains": {
    "catalog-products": {
      "file": "catalog-products.json",
      "title": "Catalog GraphQL API",
      "endpointCount": 1
    },