docs(openspec): add Vale as a second static-tier engine

[thecodedrift]

Draft — not ready for review. Spec only; no implementation yet. Opened to keep the work on the remote.

Rescoped. This change previously carried the layout, the migration, the engine, and the knowledge topic together — 44 tasks across ten groups. Since an OpenSpec change has to land complete in a single PR, that could never merge. The layout and migration moved to #73; what remains here is 22 tasks across 4 groups.

Makes the scaffolded .taskless/vale/ directory actually execute, and adds the knowledge an agent needs to decide when a rule belongs there at all.

Vale runs as a second static-tier engine: resolve its binary, run vale --config .taskless/vale/.vale.ini --output=JSON --no-exit over the target paths, and map findings into the shared CheckResult, stripping the rules. check-name prefix and normalizing severity. Static-tier is a verified property rather than an assumption — Vale's Tengo script sandbox exposes only text/math/fmt, with os/io/exec reporting "module not found", so a Vale rule cannot reach the host. Trust therefore equals ast-grep's, and a subprocess timeout bounds a runaway loop.

Per-rule scoping lives in .vale.ini matchers — [<glob>] rules.<name> = YES/NO, where enables union across matchers and a disable wins regardless of order (all verified). Because one rule's scoping can scatter across several matchers, each Taskless-owned matcher carries a tskl)-namespaced breadcrumb naming its owning rule; Vale accepts and silently drops unknown keys, so they ride inside the config rather than in a sidecar. Verify uses per-rule pass//fail/ fixture directories with an isolating .vale.ini generated at verify time, mirroring ast-grep's valid/invalid.

With two static engines, check runs them concurrently and merges into one result set, and an unavailable engine is reported without aborting the others.

The engine-selection topic ships here rather than with the layout, because it names sg/vale/runtime as things an agent can actually choose between — only true once Vale executes. Two constraints are written into the spec because they are the failure modes: engine selection is a different axis from route's authoring destination, and a different axis from trust tier, since sg and vale are both static-tier and only runtime involves login, reconcile, and signing. Ambiguity defaults to sg, stated as a property — the default names an engine known to be available — so it stays correct wherever a route can be withheld or a binary missing.

stack: openspec-archived will be red until the change is implemented and archived. That is expected: archiving now would delete the spec before anything is built against it.

Where this sits

Each change is independently landable: one OpenSpec change, one PR, archived on merge. The archive gate requires it — a tip PR must leave openspec/changes/ empty — so nothing here is stacked and none of these depend on a shared branch.

PR	Change	Prerequisites
#70	knowledge prompt export	none
#72	Vale binary packages	none
#73	partition rules by engine	none
#71 (this PR)	Vale engine + engine-selection topic	#73 (executes the vale/ directory it scaffolds) and #72 (needs a binary to resolve)

Only #71 has prerequisites. The other three can land in any order.

#70 and #71 are coupled by exactly one line: whichever lands second adds the engine-selection topic to TOPICS. Ordering between them doesn't matter.

Downstream, the generator's decision router (TSKL-279) needs a published release containing #70 and #71. It consumes a normal release — no prerelease, no path dependency — so it waits without blocking anything here.

Fixes OSS-21