Add UI to select [documents:search]-only API keys in block settings

Problem/Motivation

Currently, users can manually input a search-only API key in the Search Block settings via a plain text field. While this allows flexibility, it is also error-prone and does not validate whether the provided key is appropriate for search-only usage (i.e., has only the [documents:search] action).

To improve usability and security, we want to offer a dropdown selector that lists only available API keys (from API Keys and Scoped API Keys) that are suitable for read-only search access. This change would provide a more guided and safer configuration process.

In addition, the use of the Key module → should be evaluated to securely store and manage the available keys.

Steps to reproduce

1. Go to the configuration form of a Search Block.
2. Locate the "Search-Only Key" text field.
3. Note that any value can be entered manually, with no validation or guidance on available keys.

Proposed resolution

• Replace or complement the current text field with a select box listing only keys that allow the [documents:search] action.
• Support keys from both API Keys and Scoped API Keys.
• Evaluate integration with the Key module → for secure key management and retrieval.
• Ensure backwards compatibility for existing blocks using manually entered keys.

Remaining tasks

• Assess how to programmatically retrieve and filter API keys based on allowed actions.
• Evaluate integration points with the Key module.
• Update the block settings form to use a select box populated with valid keys.
• Implement fallback or manual entry option (if needed).
• Test key selection behavior and ensure correct key is used at runtime.

API changes

No API changes expected.

Data model changes

Minor change to block config schema to support storing selected key reference instead of raw string (if using Key module).

Security considerations

Using a select box instead of free text input reduces the chance of misconfiguration and use of overly permissive keys.

However, if a valid search-only key is exposed (e.g., via browser dev tools), it could be used to launch a DDoS attack against the Typesense server. Typesense itself does not include DDoS protection.

The recommended approach to mitigate this is to place each Typesense node behind a Cloudflare DNS endpoint with the proxy setting enabled and SSL mode set to Full. This provides additional security against such attacks.