Refactor OPDS Feed Implementation

We'd like to move to a feed generation strategy where all we need to do is pass in a `LennyAPI.Item` db object and then the `search` method can centralize and DRY the process for fetching Lenny records, searching Open Library, and then attaching the Lenny record to the right Open Library record:
```
Catalog.create(LennyDataProvider.search(limit=25, Item=LennyAPI.Item))
```

If there's no query present, we:
• `lenny_records` = fetch `limit` items from `LennyAPI.Item`
• `search_records` = we construct an Open Library search from the `openlibrary_edition` of these `lenny_records`
• We then loop over the `search_records` and and attach the appropriate `lenny_record`

If the *is* a query present... In the *future* (we can't do this yet), we:
• search Open Library for the `query` and our instance's Lenny ID as a `provider`
• We then parse the results to extract all the `openlibrary_edition` keys out into a list
• We use this list of `openlibrary_edition` keys to then get `lenny_records` from the `LennyAPI.Item` db
• We then loop over the `search_records` and and attach the appropriate `lenny_record`

This requires a significant refactor to https://github.com/ArchiveLabs/pyopds2_lenny

Start by tracing LennyDataProvider.search and Catalog.create, then inspect the referenced pyopds2_lenny implementation to locate the current feed-generation paths. The refactor is complete when the no-query flow accepts a LennyAPI.Item provider and centralizes fetching, Open Library searching, and record attachment; query support is explicitly future work.

Written by the indexing model from the issue text.