docs: correct the searchControls constraint and exposed claims

[chuckmeyer]

Follow-up to #21, fixing two contradictions that PR introduced.

1. constraint is not numeric-only

The prose said constraint appears only on the numeric parameters, while the table two lines below listed constraint for attributesToRetrieve and responseFields. A flat contradiction — I had conflated the key exists with it carries a {min, max} shape.

Re-derived from 21 indices across the 12 live agents rather than from memory:

Parameter	constraint key	merge key	ever populated
hitsPerPage	yes	no	constraint = {min, max}
page	yes	no	never
attributesToRetrieve	yes	yes	never
responseFields	yes	yes	never
distinct, facets	no	no	—

So four parameters carry a constraint key and only hitsPerPage was ever seen with one populated. merge was null in every record, which means both its purpose and whether constraint on those two takes the {min, max} form are unknown. The README now says exactly that instead of over-claiming.

2. exposed described a constraint that may not exist

"vary the value within its constraint" is wrong for distinct and facets, which have no constraint key. Reworded:

exposed: true lets the LLM choose the value at query time; exposed: false fixes it at default. Where a constraint is present and set, it bounds what the LLM may choose.

Note on provenance

The distinct and facets shapes in this table were observed on a test agent that has since been deleted, so they are no longer reproducible from the account. The observation was real and recorded at the time, but anyone re-deriving this table from live data today will find those four parameters null throughout. That is part of why the section states its provenance rather than presenting itself as a schema.

Docs only; no code change.

🤖 Generated with Claude Code