[Search] Regenerate azure-search-documents for 2026-05-01-preview (#46933)

Bump to 12.1.0b1, regenerated from spec
Azure/azure-rest-api-specs@8be8c75.
Adds new knowledge source kinds, V2 tokenizers, SharePoint connector
configuration, and send_request on all clients. See CHANGELOG for the
full feature and breaking-change list.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: hizixin

sdk/search/azure-search-documents/.github/skills/azure-search-documents/SKILL.md

@@ -122,7 +122,9 @@ For each new method, pick the exposure path:
 
 5. **List projection wrapper** — for `list_*`. Add a `select` parameter, a name-only projection via `cls` callback (`list_index_names`, `list_indexer_names`, `list_skillset_names`), or convert a generated projection type back to the canonical model via `_convert_index_response`.
 
-6. **Re-export via `__all__`** — any NEW symbol you add or override in `_patch.py` MUST be appended to that file's `__all__`. Otherwise `patch_sdk()` will not surface it.
+6. **Friendly-input wrapper** — when a generated parameter takes a structured string the caller would otherwise assemble by hand, add an optional higher-level kwarg that builds it from simpler inputs. Keep the raw parameter accepted too.
+
+7. **Re-export via `__all__`** — any NEW symbol you add or override in `_patch.py` MUST be appended to that file's `__all__`. Otherwise `patch_sdk()` will not surface it.
 
    ```powershell
    venv python -c "import azure.search.documents as m; print(sorted(m.__all__))"

sdk/search/azure-search-documents/.github/skills/azure-search-documents/references/release.md

@@ -19,23 +19,26 @@ If the current branch differs from the inventories in many places, consider rege
 
 ## CHANGELOG conventions
 
-Use `azsdk_package_update_changelog_content` to draft entries, then review and adjust.
+### Drafting changelog entries
 
-The generated SDK code is the source of truth for CHANGELOG content. If something exists in generated code, treat it as present. Fall back to the TypeSpec config in the spec PR only when the generated code is ambiguous.
+1. Start from the spec PR's `CHANGELOG.md`. Map its sections to ours and use it as the candidate list of what changed.
+2. Treat generated SDK code as the source of truth. Confirm each candidate entry exists in the current generated code with `venv python -c "from ... import X; print(X)"`.
+3. Group entries by symbol kind and feature theme when meaningful. Kinds are `clients`, `enum members`, `models`, `operations`, `parameters`, `properties`; combine kinds inline when a group includes more than one kind.
+4. Write each group as a lead-in bullet with an indented sublist. Use one of these patterns:
+   - `Below <kinds> are added [or changed] [for <theme>]`
+   - `Below <kinds> are renamed`
+   - `Below <kinds> do not exist in this release`
+5. Sort entries within each sublist alphabetically by fully qualified name.
 
-After drafting the CHANGELOG, verify both directions:
+### Checking whether a symbol exists in a release
 
-1. Code to CHANGELOG: for every changed item in generated code, verify it is reflected in `CHANGELOG.md`.
-2. CHANGELOG to code: for every item in `CHANGELOG.md`, verify it matches actual code.
-
-Use the import checks in `SKILL.md` plus targeted `venv python -c "from ... import X; print(X)"` checks for individual symbols.
-
-Sort lists within each CHANGELOG section alphabetically by fully qualified name.
+- Spot-check: `git show azure-search-documents_<prev-version>:sdk/search/azure-search-documents/<path>`.
+- Full dump: `pip install azure-search-documents==<prev-version>` into a temp venv, dump via `dir()` / `inspect.signature`, diff against current. Run from outside the package root or local source shadows the wheel.
 
 ### Preview releases
 
 - `Features Added`: list changes since the previous preview release.
-- `Breaking Changes`: list breaking changes since the previous preview release. Put this beta-only disclaimer before the list:
+- `Breaking Changes`: list breaking changes since the previous preview release. Prepend this beta-only disclaimer:
 
 ```markdown
 > These changes do not impact the API of stable versions such as <latest GA version>.
@@ -46,8 +49,8 @@ Sort lists within each CHANGELOG section alphabetically by fully qualified name.
 
 - `Features Added`: list changes since the previous GA release. Do not compare against the latest preview.
 - `Breaking Changes`: when both categories apply, group them in this order:
-  1. GA-to-GA breaking changes, with no disclaimer.
-  2. Preview-to-GA breaking changes, after this beta-only disclaimer:
+  1. Breaking changes since the previous GA release, with no disclaimer.
+  2. Breaking changes since the latest preview in this GA's minor, prepended with this beta-only disclaimer:
 
 ```markdown
 > These changes do not impact the API of stable versions such as <previous GA version>.

sdk/search/azure-search-documents/.github/skills/azure-search-documents/references/testing.md

@@ -64,9 +64,17 @@ New live tests require new [Test Proxy](https://github.com/Azure/azure-sdk-tools
 
 This checklist is mandatory for every test change. Do not add or update tests without checking each item below.
 
-1. Start from current SDK source. Prioritize public behavior owned or customized by the Python SDK, especially `_patch.py` and other hand-written code paths.
+1. Start from current SDK source. Test SDK-owned behavior, especially `_patch.py` and other hand-written code paths. Do not add package tests solely for pure generated models, enums, or fields; validate generated exports through public API surface review instead.
 2. Prefer unit tests whenever the behavior is SDK-owned and can be proven without HTTP. Use playback or live tests only when the service contract matters.
 3. Place each test in the file that matches the public SDK surface and subject that owns the final assertion: unit `test_<surface_or_helper>.py`, async unit `test_<surface_or_helper>_async.py`, live `test_<public_surface>_<subject_family>_live.py`, async live `test_<public_surface>_<subject_family>_live_async.py`.
-4. Name each test after the primary public SDK method or surface under test: `test_<method_or_surface>_<scenario_or_behavior>`. If a parametrized test covers a family of related methods, use a clear family name instead of listing every method.
-5. Use deterministic fixtures in Python builders. Share repeated setup and keep scenario-specific setup in the test.
-6. Add sync and async together when both public surfaces exist, with matching test names unless the public API differs.
+4. Name each test class after the public SDK surface or subject family it groups: `Test<SurfaceOrFamily>`.
+5. Name each test after the primary public SDK method or surface under test: `test_<method_or_surface>_<scenario_or_behavior>`. If a parametrized test covers a family of related methods, use a clear family name instead of listing every method.
+6. Use deterministic fixtures in Python builders. Share repeated setup and keep scenario-specific setup in the test.
+7. Add sync and async together when both public surfaces exist, with matching test names and test class names unless the public API differs.
+
+## Gating preview-only tests
+
+1. Wrap each test scenario that depends on preview-only surfaces with `require_capability(...)`; pass every preview surface the scenario uses.
+2. Register capabilities in `tests/_capabilities.py` at the narrowest public surface: new class, new method, method kwarg, model field, or enum member. Use dotted names that match the surface under test, for example `SearchClient.search.query_rewrites`; set `owner` to the public object that must exist and `kwargs` only for method kwargs, model fields, or enum members.
+3. Avoid importing preview symbols at module load. Use strings, JSON, local imports, or `hasattr` checks when needed.
+