Feat: add --fzf-command option to override FZF_DEFAULT_COMMAND

[alberti42]

Rationale of this PR

This change adds an optional --fzf-command argument to the fzf plugin. When provided as a string, the plugin sets FZF_DEFAULT_COMMAND for the spawned fzf process. This enables users to control the candidate list (e.g., fd -d=1) without fragile chain of piped commands, or custom argument parsing.

I also published a standalone plugin at fzf-plus.yazi so users can try it immediately while this PR is under review.

This PR solves

• Keeps the plugin minimal and aligned with fzf’s own configuration model based on FZF_DEFAULT_COMMAND.
• Works cleanly with Yazi’s argument parsing (no POSIX-style token splitting).
• Avoids brittle fallbacks and complex parsing.

Usage example

[[mgr.prepend_keymap]]
on   = "z"
run  = "plugin fzf -- --fzf-command='fd -t=d -d=1'"
desc = "Jump via fzf (limited depth, only directories)"

Notes

• Only string values are accepted; if --fzf-command is present but not a string, the plugin shows an error.
• Behavior is unchanged when the option is absent.
• When a selection exists, fzf still receives the selection via stdin (default command is ignored, as expected).

[alberti42]

Hi @sxyazi! I wanted to check in on this PR. I find the --fzf-command option genuinely useful for controlling the candidate list, and I think it fits naturally into the existing plugin design.

That said, I'm aware this might not align with your vision for the built-in fzf plugin. A few questions:

• Would you have time to take a quick look and share your thoughts?
• If you're interested, I'm happy to iterate on the implementation based on your feedback or add features.
• If you'd rather keep the built-in plugin minimal, I'm also fine closing this; interested users can rely on the standalone https://github.com/alberti42/fzf-plus.yazi/ plugin meanwhile.

No rush at all - just wanted to make sure it's on your radar. Thanks a lot!