Unify add and search acquisition flows

[magrhino]

Pre-flight

• I searched existing issues and this isn't a duplicate
• I checked the roadmap and this isn't already planned

Problem

Bindery has several related entry points for the same broad user job: "I want to find something and decide what Bindery should do with it."

Today those entry points are split across:

• Add Author
• Add Book
• Series add flows
• Search Indexers
• Page-local library filters and search fields

Each surface is useful on its own, but the user has to choose the right entry point before Bindery knows what they are looking for.

Examples:

• A query like Dune could mean an existing local book, a metadata book to add, an author, a series, or an indexer release.
• Add Book supports title, ISBN, and ASIN lookup, but the user has to know where that modal lives.
• Add Author asks for monitoring and download choices before the selected author gives the user enough context.
• Search Indexers is separate from metadata search, even though a user's intent may start from one query.

This is mostly a product model and UX question, not a bug.

Proposed solution

I'd like maintainer direction on whether Bindery should move toward a more unified acquisition flow.

My recommended low-risk path is staged:

Stage 1: normalize the existing add flows

• Make Add Author search-first.
• Move monitoring, media type, root folder, metadata profile, and auto-grab choices into a confirmation/customize step after the user selects an author result.
• Bring Add Book and Add Author onto the same modal contract: dialog semantics, i18n, inline errors, consistent Cancel behavior, and focused tests.
• Keep configuration compact by default, with a "Customize monitoring" affordance for users who need to override defaults.

Stage 2: improve entry points

• Add a first-class Add Book entry point from the Books page.
• Consider replacing the Authors toolbar's separate Add Book / Add Series / Add Author buttons with a single Add menu if that fits the intended product model.
• Keep Search Indexers as a dedicated power-user page for direct release searches.

Stage 3: consider a global acquisition search

If the staged direction feels right, build toward a global search/add panel or app-shell search bar:

1. User enters a title, author, ISBN, ASIN, or series name.
2. Bindery groups results by type:
   • Existing library matches
   • Metadata books
   • Authors
   • Series
   • Indexer releases, when configured
3. User chooses a result.
4. Bindery presents the relevant action:
   • Open existing item
   • Add book to wanted
   • Add author and monitor
   • Search/grab release
   • Add to series

The important behavior is search first, then action and automation choices second.

Alternatives considered

1. Keep the current page-specific modals only.

   • Lowest churn, but it does not solve discoverability or the "which add flow do I open?" problem.

2. Build the global search/add panel immediately.

   • Potentially the best long-term model, but it is a larger PR and may need maintainer product direction before implementation.

3. Fold all direct release search into Add Book.

   • Simpler than a global panel, but it risks hiding the current Search Indexers power-user workflow.

Additional context

The roadmap already notes that direct title/keyword indexer search has shipped at /search. This proposal is different: it is about unifying the acquisition decision across local library matches, metadata search, author search, series search, and indexer releases.

Before I implement anything, I'd like maintainer guidance on these questions:

1. Should Bindery move toward a global search/add command, or keep page-specific add flows?
2. Should Add Author become search-first, with monitoring options shown after selecting an author?
3. Should Add Book be first-class on the Books page?
4. Should indexer search stay separate long-term, or eventually appear in the same acquisition surface?
5. If the direction sounds right, would you like me to take the Stage 1 work first?