spec(3.9): booking_window and its members are optional

[maoryeh]

ServicePolicies.booking_window was Required, and schemas/catalog.json
required all three of min_advance, max_advance and slot_interval inside it.
A business that constrains none of them had no conformant way to say so.

The result is that the field cannot be trusted for the thing it exists for. An
implementation whose upstream states no window has to invent values to satisfy the
schema, and a consumer then cannot tell

"max_advance": "P365D"   // the merchant allows booking a year ahead

from

"max_advance": "P365D"   // the implementation had nothing to say

slot_interval is the sharpest case. A business that publishes no generation
interval has no honest value to send, so a required field turns into a fabricated
claim about when appointments can start — and §3.6.3 already warns consumers not
to substitute it for a snapshot's own start_interval, which only matters if the
value means something.

Found implementing the Wix adapter, where slot_interval is not derivable from
anything upstream and every service therefore published the same invented
PT30M.

The change

booking_window becomes optional, each member becomes independently optional, and
the presence rule is stated:

A business that constrains how far ahead or how late a booking may be made
MUST state the constraint it enforces. A business that does not constrain it
MUST omit the member... A consumer MUST NOT read an omitted member as an
unbounded window, a zero minimum, or any default interval; it means the business
has stated nothing, and the consumer learns the real answer by attempting the
booking.

This is the pattern the specification already uses elsewhere rather than a new
one. §5.2 says a business that does not hold slot capacity MAY omit
expires_at, and §5.6 puts it plainly: presence is the advertisement. A window
constraint is the same kind of claim.

Backwards compatible for producers: everything valid before is still valid. It
relaxes an obligation rather than adding one, so a consumer that already reads
these fields must now handle their absence — which it had to handle anyway for
no_show, and which is strictly better than reading an invented value as fact.

Mirrored in schemas/catalog.json and site-docs/specification/service-catalog.md.
tools/usp_check.py all reports the same results as clean master: schemas, refs,
vectors and coherence ok, and the same 56 pre-existing authority failures, which
want a built site.

🤖 Generated with Claude Code