split instrument availability into constraints and options axes

[igrigorik]

Current #424 shape put everything an instrument declares — presence, per-field
constraints, accepted card brands, and credential families — into one
constraints bag. Prototyping a resolver against that shape showed the cost:
to enforce field requirements a consumer must first classify every key by
resolving its concrete schema (is this a field constraint? a value menu? a
typed family?). That classification is the whole problem — it needs the target
schema, defeats "compile from data alone," and produced real bugs in the
prototype (per-key allOf composition, and a required name collision).

Partition the bag into two sibling axes:

• constraints — field requirements over the instrument's OWN fields (an
  Object Constraint: required plus one direct key per constrained field).
  Compiles to a JSON Schema overlay (required + properties) a standard
  validator runs.
• options — accepted value menus (brands) and typed families
  (credentials), resolved by data lookup and never part of the overlay.

With the menus and families moved to options, constraints holds nothing but
required and field constraints — and object_constraint now enforces exactly
that: every non-required key is a nested Object Constraint or a Value
Constraint (recursing via $ref "#"). Compiling the overlay is therefore a
pure data walk — no schema resolution, no classification. That is the win: the
resolver is clean by construction, not by careful bookkeeping. Proven in the
ucp-schema resolver prototype (~20-line compile; the compiled overlay enforces
presence and allowed values against real instances).

Trade-offs:

• constraints is deliberately not a literal JSON Schema: fields are direct
  keys, so a consumer compiles it (take required, lift field keys under
  properties). A properties-keyed sub-map would make it literal but collide
  the JSON Schema properties keyword with the data key when a schema narrows a
  nested field. The compile is trivial, and a resolver runs regardless.
• required is reserved inside a constraint object, so a field literally named
  required can be listed as present but cannot carry a nested constraint.
  Rare, and documented.
• The shape still does not enforce name resolution (does the named field exist
  on the target?). Unchanged from before; a lint pass can add it later — the
  partition makes it tractable, since every non-required key is unambiguously
  a field name.

[jamesandersen]

Not introduced here ... but unless I'm missing something, I don't see a token_credential.json#/$defs/constraint?

[jamesandersen]

nit: inclusion in schema-authoring.md implies use across UCP broadly so "handlers" could be slightly confusing here.

[jamesandersen]

Should we clarify whether the required should include the keys from options? They are presumably required (with more than just presence)