Always try to match a master file by @file meta

[tapple]

Always try matching a master file via the @file comment, regardless of any setting:

• It's much easier to get working than matching by script name for all but the most trivial of repository layouts/script naming conventions
• It's easier to explain
• It's useful even if the @file comment is not auto-generated

Motivation

These two PR's were developed and merged independently, at about the same time:

• Reduce config switches for meta output #50
• Add the option to treat the viewer file as master #55

However, these two PR's have a functional conflict: #55 is not very useful without the setting that #50 removed:

• 55 is only useful if the plugin does not modify the local file at all before sending it to the viewer (otherwise the file can get duplicate headers added every round trip viewer -> plugin -> viewer
• But 50 is tied the checking of @file to modifying the script on sending to the viewer
• So now 55 only works well if you use script name matching, not @file matching
• Which is not very useful

This PR resolves the functional conflict:

• The setting from Reduce config switches for meta output #50 is still removed
• and Add the option to treat the viewer file as master #55 is now useful without the removed setting

---

An example of a situation I got today:

-- ================ sl-vscode-plugin meta ================
-- @file lsl_scripts/vehicle/notecard.luau
-- @hash 4c1fc55bb53e3855a9e40cc6e7abe200fa0329e684d8a1be356f7a4093df4448
-- @date 2026-01-31 03:59:55
-- =======================================================
-- ================ sl-vscode-plugin meta ================
-- @file lsl_scripts/vehicle/notecard.luau
-- @hash 9297b12d42e0b85d5c73a247fd7d093022ffded06e193978fd685b4906145d73
-- @date 2026-01-31 03:58:59
-- =======================================================
-- @file lsl_scripts/vehicle/notecard.luau
--!strict
--!nolint LocalUnused
-- # selene: allow(unused_variable, multiple_statements))
...

I added the third @file comment manually, some weeks ago. The other two got added by the plugin today, after 2 viewer -> plugin -> viewer round trips

[WolfGangS]

Yeh when I switched that config check, I hadn't considered users adding the flag themselves manually. I can't really see this change causing any issues.