[Feature Request] Improve Search to Ignore Punctuation/Dots in Filenames

[gfolgert]

Description
The current search functionality requires exact character matching, which causes searches to fail when filenames use common delimiters (like periods or underscores) instead of spaces.

• When users type standard queries with spaces (e.g., "Blade Runner"), the system cannot locate files that follow standard media naming conventions (e.g., "Blade.Runner").
• This creates friction, as users must guess the exact punctuation used in the filename or rely on external workarounds to find their media.

Expected behaviour
When submitting a search query with spaces, the search engine should ignore common delimiters in the filenames and return the matching files. For example, a search for Blade Runner should successfully find and display Blade.Runner.mkv, Blade_Runner, and Blade-Runner.

What is happening instead?
The search engine processes the query as a strict string match. Because the space character in the query does not perfectly match the period or underscore in the filename, zero results are returned.

Additional context

• Many self-hosted media collections are managed by automation tools (like Radarr or Sonarr) or downloaded using standard release naming conventions, which heavily utilize periods or underscores instead of spaces.
• Implementing a simple "punctuation normalization" (converting dots/underscores to spaces before comparing) or "tokenized search" (splitting the filename into searchable words) would completely resolve this issue and vastly improve the user experience.

How to reproduce?

1. Create a new folder or dummy file named Blade.Runner
2. Navigate to the file browser's search bar.
3. Type the query: "Blade Runner" and hit search.
4. Observe that the search returns 0 matches.

[butonic]

Currently, we do what is called a 'Match' search.

Web sends a query like this:

    <oc:pattern>(name:&quot;*New file*&quot; OR content:&quot;New file&quot;)</oc:pattern>
    -> (name:"*New file*" OR content:"New file")

Web could split the text in the search field at spaces and then send sth like this:

    <oc:pattern>((name:&quot;*New*&quot; AND name:&quot;*file*&quot;) OR (content:&quot;New&quot; AND content:&quot;file&quot;))</oc:pattern>
    -> ((name:"*New*" AND name:"*file*") OR (content:"New" AND content:"file"))

The challenge is deciding when to split the user entered string into individual search terms and when to use it as a single search term. The google search uses quotes to make this explicit.

The server api allows sending structured queries. The iOS client uses it. IIRC we want to make the search bar in web more powerful as well.

@AlexAndBear Supporting only quotes for now might be a quick win?