Configurable feature to restrict retrievals of certain CIDs to certain wallets

### Checklist

- [X] This is **not** a new feature or an enhancement to the Filecoin protocol. If it is, please open an [FIP issue](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0001.md).
- [X] This is **not** brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on [the Boost forum](https://github.com/filecoin-project/boost/discussions/categories/ideas) and select the category as `Ideas`.
- [X] I **have** a specific, actionable, and well motivated feature request to propose.

### Boost component

- [ ] boost daemon - storage providers
- [ ] boost client
- [ ] boost UI
- [X] boost data-transfer
- [x] boost index-provider
- [ ] Other

### What is the motivation behind this feature request? Is your feature request related to a problem? Please describe.

As an enterprise client I want to restrict retrievals from the SPs I work with such that only I can retrieve my CIDs from an SP, even if the content of those CIDs is encrypted. This provides an additional layer of security where even if modern encryption algorithms are broken by advancements in computing or some other security breach, the client's data would not be accessible.

High-level client journeys include:
- As a client I want to be able to define a set of SPs
- As a client I want to define a set of "deal-making wallets."
- As a client I want to define a set of "retrieval wallets."
- As a client I want to be able to update my sets of "deal-making wallets" and "retrieval wallets."
- As a client, the data stored with any of the given SPs as part of a deal made with any of the "deal-making wallets" should only be retrievable by any of the "retrieval wallets" at the time of the retrieval request.
- As a client, in the future, I would want to be able to define multiple sets of SPs each with their own set of "deal-making wallets" and "retrieval wallets."

High-level SP journeys include:
- As an SP, I want to be able to configure one or more rules in Boost for "wallet-restricted retrievals." Each rule should contain: a set of "deal-making wallets" and a set of "retrieval wallets."
- As an SP, for each retrieval request, the request should be filtered according to the "wallet-restricted retrievals" rules whereby any retrieval request for a CID made by a wallet in the list of "deal-making wallets" is restricted to only wallets in the set of "retrieval wallets" for that given rule.
- As an SP I would want to be able to delete a "wallet-restricted retrieval" rule.
- As an SP I would want to be able to update the set of "deal-making wallets" and "retrieval wallets" in an existing "wallet-restricted retrievals" rule.

### Describe the solution you'd like

I'm open to input here, but one idea is to ...

Require the client to send a list of "deal-making wallets:" and "retrieval wallets" to the SPs they want to make deals with.

Provide each SP a way in Boost to create a "wallet-restricted retrievals" rule including the client-provided list of "deal-making wallets" and "retrieval wallets."

Once configured, retrievals for any CID made by any of the wallets in a "wallet-restricted retrievals" rule would be restricted across all protocols to only the wallets in the list of "retrieval wallets" for that rule.

### Describe alternatives you've considered

We've considered CID Gravity and JWT implementations. In the future we expect clients to require proper access controls with roles, users, and entitlements mapped to CIDs or containers/buckets of CIDs.

### Additional context

This feature is required by several enterprise clients.

Start by reviewing the boost data-transfer and boost index-provider components, then trace how retrieval requests are authorized and how CID Gravity or JWT alternatives relate. Define the configuration and request-handling entry points for wallet-restricted retrieval rules, along with tests for rule creation, updates, deletion, and enforcement. Done means configured rules restrict matching retrievals to the permitted retrieval wallets across the supported protocols.

Written by the indexing model from the issue text.