Is your feature request related to a problem? Please describe.
Currently, the Nyxt password manager integration with pass will query for a username by decrypting the secret file and searching for a key by one of the following names: login/user/username. This convention, however, is not the only one in common use.

Many users (myself included) choose to instead use the convention of including the username as part of the secret's filename (e.g.: [email protected]) so that it may remain easily and automatically disambiguated with other credentials in the same domain (e.g.: Microsoft SSO).

For illustrative purposes, here's what a password store directory using this format might look like:

graph TD
    A["~/.password-store/"]-->B["example.com/"]
    A-->C["sso.example.net/"]
    B-->D["[email protected]"]
    C-->E["[email protected]"]
    C-->F["[email protected]"]
    A-->G["[email protected]"]
   class D,E,F,G secret
   classDef secret stroke:#333

Because I follow the above convention rather than storing usernames as keys in the encrypted file body, my credential usernames cannot currently be retrieved by Nyxt when invoking copy-username. I'd very much like it if Nyxt was made to support this convention on an optional basis so that I could take full advantage of its password management features without having to considerably rework my existing setup.

Relevant prior art:

• Emacs auth-source
• Qutebrowser qute-pass
• rofi-pass
• Android Password Store (via PGPainless)

Describe the solution you'd like
When copy-password is invoked with the password-store backend active, I would like the backend to first attempt extracting the username from the filename. Ideally, it should be able to automatically detect and extract the expected username from each of the following common well-known filename patterns (source)

Describe alternatives you've considered
I've considered abandoning this scheme and moving the username into the content of the secret file. This is probably viable, but I'd very much rather not rewrite and reencrypt hundreds of secrets when my current & preferred format is quite standard and commonly supported elsewhere -- not to mention that reencrypting hundreds of keys would take me hours since I am using a strict mandatory-touch hardware-based encryption.