fix: allow action scripts to be found inside the style directory

[aireilly]

Hopefully this makes sense. I did create this with Claude, tested locally and it seems to work fine :/

Summary

• When a suggest action references a .tengo script, Vale only searches config/actions/ for the file
• But vale sync drops the config/ directory for style-only packages — it only copies the folder matching the package name (e.g., RedHat/)
• This creates an impossible packaging constraint: the script must be in config/actions/ to be found, but that directory is silently dropped during sync

This PR adds a fallback so the suggest action also searches the style's own directory (e.g., <StylesPath>/RedHat/NoGerundsInTitles.tengo), matching how dictionaries work — they live inside the style folder and get included in a simple zip -r RedHat.zip RedHat.

Why this affects us

The vale-at-red-hat package ships as a style-only zip (zip -r RedHat.zip RedHat). When we added a suggest action with a Tengo script (NoGerundsInTitles), we hit a wall:

1. Putting the .tengo file in config/actions/ and adding config to the zip (zip -r RedHat.zip RedHat config) doesn't work — installPkg at sync.go:94 enters the style-only code path and only copies RedHat/, silently dropping config/
2. Restructuring the zip with a styles/ wrapper would work but breaks the simple packaging model that every other style-only package uses
3. The only viable option is to put the script inside RedHat/ alongside the rule files — but then FindConfigAsset can't find it because it only searches config/actions/

Lookup order (backwards compatible)

1. config/actions/<script> (existing behavior)
2. <StylesPath>/<StyleName>/<script> (new fallback, derived from alert.Check)

Test plan

• Verified locally: vale sync with flat RedHat.zip, suggest action finds RedHat/NoGerundsInTitles.tengo and returns correct suggestions ("Running" → "Run")
• Existing tests pass (no change to config/actions/ lookup)

🤖 Generated with Claude Code

[StaticRocket]

Hm. I kind of wish things were a little more linked so we could simply traverse to fetch that data. Something like:

Style {
	name: "..."
	path: "..."
	rules: [
		Rule {
			name: "..."
			path: "..."
			style: &Style
		}
	]
}

Alert {
	name: "..."
	rule: &Rule
}

Could cut down on a lot of duplicate struct values and allow us to do more advanced asset lookups without having to rely on arbitrary string parsing.