fix(fyler-nvim): update config for fyler v2 rewrite

[razvan]

Description

NOTE: yes I used Claude Code to create this PR but I tested it successfully.

fyler.nvim's 2026-06-14 rewrite (1bb18a0 "refactor!: Rewrite the whole plugin") replaced the nested views.finder.* config with a flat schema and renamed the window kind preset float → floating. The current spec calls toggle { kind = "float" }, which no longer resolves to a preset, so opening fyler on the latest version errors with:

after the second argument: expected table, got nil

(config.get_config → vim.tbl_deep_extend('force', M.DATA, M.DATA.kind_presets["float"] --[[nil]], ...))

Migration

old (views.finder.*)	fyler v2
default_explorer	use_as_default_explorer
win.kind	top-level kind
win.border	kind_presets.floating.border
keymap kind = "float"	kind = "floating"

views.finder.indentscope.markers has no v2 equivalent (the rewrite replaced the custom indent marker with a boolean ui.indent_guides), so the custom glyph is intentionally dropped in favour of indent_guides.

Verification

Tested against fyler a588c75 (v2):

• old spec reproduces the error above
• new spec resolves kind=floating border=rounded use_as_default_explorer=true indent_guides=true and toggle { kind = "floating" } opens without error

[github-actions]

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

• If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

• If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

• Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

• README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

• Entry returns a single plugin spec with the new plugin as the only top level spec (not applicable for recipes or packs).

• Proper usage of opts table rather than setting things up with the config function.

• Proper usage of specs table for all specs that are not dependencies of a given plugin (not applicable for recipes or packs).