docs: add Leads list & search (FIND) API reference

[vaidik2412]

Documents GET /api/v1/businesses/:urlKey/leads, the list/search endpoint added in refrens/serana#4781 with the Elasticsearch indexing fix in refrens/seeds#65.

Adds a List and Search Leads section to docs/leads.mdx, following the same structure as the existing Create and Edit sections, and updates the page intro to mention listing.

What it covers

• Pagination and sorting — $limit (default 10, max 50), $skip (max 1000), and the four sortable fields.
• Four filter groups — structured filters matched by name, exact-match lookups, ranges, and free-text search. Multi-value syntax (comma and $in) and match-any-within / match-all-across semantics.
• Ranges — createdAt, followUpDate, budget, plus the followUpDate=none special case and its mutual exclusion with the range bounds.
• Free-text — that it runs on Elasticsearch, that it reorders results by relevance, and that it returns SEARCH_UNAVAILABLE rather than silently degrading where ES is off.
• Unknown values vs no matches — a table making the deliberate split explicit: an unknown pipeline or tag is a 400 naming the offending value, while an unresolved id is an empty page.
• Query safety — the allowlist, the refusal of server-applied fields like business and isRemoved, and the $in-only operator rule.
• FIND error codes — all twelve, with the condition for each.

Verification

Every documented behaviour was exercised live against prod using the refrens-video-demo business: 21 read-only scenarios plus 6 Elasticsearch probes, all passing. That includes the four ES scenarios serana#4781 listed as environment-blocked (free-text ORing across fields, .keyword filter matching, populate, and relevance sort), which are confirmed working.

Also verified from source that find, get and create all return through the same mapInternalToExternal, so the shape claim in the intro holds, and that optional fields are omitted when a lead has no value for them.

npm run build passes and the section renders correctly.

Review passes applied

An independent reader-effort review (second commit) fixed seven things, most importantly a factual error: the intro said filters fall into three groups while four were documented — ranges were missing from the list. Also: data[0].items is now named in the intro rather than only in the response block; the free-text and assignedTo rules are split so each sentence carries one rule; both followUpDate failure conditions are stated inline in the error table; the duplicated business/isRemoved rule is trimmed to one home; and status is now separated from the CRM-configured filters, since it is a fixed Refrens set rather than business configuration.