feat: add response-carried request constraints

[igrigorik]

Depends on #657.

Static request schemas describe the inputs a Business generally accepts, but not narrower requirements for a particular transaction. Without response-time constraints, a Platform learns that a negotiated quantity is fixed or an otherwise optional field is required only after submission fails—or through domain-specific constraint formats.

PR #657 establishes the ambient ucp protocol namespace and central member registry. This PR adds request_constraints to that vocabulary instead of inventing a parallel structural namespace.

• Registers response-only ucp.request_constraints in ucp.json#/$defs/members.
• Defines a closed JSON Schema Draft 2020-12 value grammar using required, properties, enum, and const.
• Lets a Business communicate and authoritatively enforce transaction-specific input constraints.
• A Platform MAY use the member to form or validate a request, or safely ignore it and rely on Business validation.
• Applies the fragment alongside the resolved request schema; both validations must pass, equivalent for validity to allOf without schema merging.
• Uses the containing ucp scope to identify the constrained parent object; adopting contracts define correspondence and lifecycle when existing operation semantics do not.

Examples

A Cart Line Item fixed at quantity 100:

{
  "id": "line_123",
  "quantity": 100,
  "ucp": {
    "request_constraints": {
      "properties": {
        "quantity": {"const": 100}
      }
    }
  }
}

A submitted card instrument that requires a billing address for this transaction:

{
  "type": "card",
  "ucp": {
    "request_constraints": {
      "required": ["billing_address"]
    }
  }
}

Boundaries

This PR does not define payment availability, custom assertion keywords, schema merging, or new outcomes and error codes. Payment-specific correspondence and availability remain downstream.