fix(query): validate --where and --sort field names against the corpus

[pablontiv]

Slice B of 3 for #63. Stacked on #127 (slice A), which is itself stacked on #124.

Root cause

Two sub-defects, one omission: a field name the user typed was never checked against the field names that exist.

§4 — the documented warning was unreachable. cmd/rootline/filter.go gates query.CheckFieldNames on a non-empty knownFields slice, and all five production call sites passed nil — graph.go, query.go, stats.go, tree.go, validate.go. The function was exercised only by its own unit test and one e2e test, both calling it directly. So a misspelled --where field — the highest-frequency user error on this CLI — was indistinguishable from "no records match": zero results, empty stderr, exit 0. In CI that reads as a green check. CLAUDE.md documented the feature as shipping.

§7 — --sort validated half its input. internal/query/sort.go treats "field absent on both records" as continue, so with a nonexistent key every comparison falls through and sort.SliceStable preserves scan order. A typo produced plausible-looking, unsorted output at exit 0 — while a bad direction was already caught cleanly with rc=1.

Approach

knownWhereFields builds one field set that both checks use:

• the query builtins query.BuildEnv always injects (path, body, type, sections),
• every key any record in the scanned corpus carries (frontmatter and derived),
• every schema: / derive: / aggregate: name the effective .stem chain declares.

The union is deliberately generous. A false "unknown field" on a name that does work is worse than the silence it replaces: it teaches callers to ignore the warning. For the same reason it returns nil for a corpus with neither records nor schema — there is nothing to check against there, and every name would look wrong.

It is computed before --where narrows the corpus, so --where 'estado == "NeverMatches"' --sort estado:asc does not report estado as unknown.

filterRecords now takes the warning writer as a parameter rather than reaching for os.Stderr, so warnings land on the command's error stream and are testable like every other output in this package.

Decisions

• --where stays a WARNING; the exit code is untouched. internal/query/field_check.go already returns FieldWarning with warning-shaped prose, and a field absent from every record is a legal filter that yields zero matches. Promoting that to rc=1 would break existing pipelines.
• --sort is an ERROR. The issue is explicit that a bad field deserves what a bad direction already gets. Unlike --where, an unsortable key cannot produce a defensible result: the output is silently in scan order and indistinguishable from a correct sort.

Evidence

Before

$ rootline query docs/ --count --where "estadoo == 'Pending'"
{"version":1,"kind":"rootline/count","meta":{"count":0},"count":0}
# rc=0, stderr empty
$ rootline stats docs/ --where "estadoo == 'Pending'"
{"version":1,"kind":"rootline/stats","by_lifecycle_state":{},"by_record_type":{},"total":0}
# rc=0, stderr empty
$ rootline tree docs/ --where "estadoo == 'Pending'"
{"version":2,"kind":"rootline/tree","root":{"name":"docs","path":"docs","total":0}}
# rc=0, stderr empty
$ rootline validate --all docs/ --where "estadoo == 'Pending'"
{"version":2,"kind":"rootline/validate-batch","results":[],...}
# rc=0, stderr empty
$ rootline graph docs/ --check --where "estadoo == 'Pending'"
No cycles or broken links found.
# rc=0, stderr empty

$ rootline query docs/ --select path,estado --sort "nosuch:asc" -o csv
path,estado
r1.md,Pending
r2.md,Done
r3.md,Pending
...
# rc=0 — scan order, silently unsorted

After

$ rootline query docs/ --count --where "estadoo == 'Pending'"
warning: unknown field "estadoo" in where expression (did you mean "estado"?)
{"version":1,"kind":"rootline/count","meta":{"count":0},"count":0}
# rc=0

$ rootline stats docs/ --where "estadoo == 'Pending'"
warning: unknown field "estadoo" in where expression (did you mean "estado"?)
{"version":1,"kind":"rootline/stats","by_lifecycle_state":{},"by_record_type":{},"total":0}
# rc=0

$ rootline tree docs/ --where "estadoo == 'Pending'"
warning: unknown field "estadoo" in where expression (did you mean "estado"?)
{"version":2,"kind":"rootline/tree","root":{"name":"docs","path":"docs","total":0}}
# rc=0

$ rootline validate --all docs/ --where "estadoo == 'Pending'"
warning: unknown field "estadoo" in where expression (did you mean "estado"?)
{"version":2,"kind":"rootline/validate-batch","results":[],...}
# rc=0

$ rootline graph docs/ --check --where "estadoo == 'Pending'"
warning: unknown field "estadoo" in where expression (did you mean "estado"?)
No cycles or broken links found.
# rc=0

$ rootline query docs/ --select path,estado --sort "nosuch:asc" -o csv
Error: unknown sort field "nosuch": no record carries it and no .stem in scope declares it
# rc=1

$ rootline query docs/ --select path,estado --sort "estadoo:asc" -o csv
Error: unknown sort field "estadoo": no record carries it and no .stem in scope declares it (did you mean "estado"?)
# rc=1

No false positives, verified by test: estado (schema), path and body (builtins), a frontmatter key no .stem declares, a valid sort key surviving a filter that matches nothing, and an empty corpus all stay silent.

Gates

Gate	Result
just check	pass, 0 issues
just test (-race)	pass
just coverage-check	pass — cmd/rootline 86.8%, internal/query 89.1%, total 89.6%

Not in this slice

§5 --field repeatability and §6 --field on non-JSON output → slice C.

Refs #63

[pablontiv]

Why this PR shows zero checks

This PR targets pablontiv/w5-issue63-output-contract (PR #127), not master. .github/workflows/ci.yml filters both push and pull_request on branches: [main, master], and GitHub matches that filter against the base branch — so no workflow fires at all. mergeStateStatus is CLEAN with an empty statusCheckRollup, which is visually indistinguishable from a fully passing PR. Tracked in #130.

Local evidence in place of CI

Every CI job was reproduced locally against this PR's head (03cf8cd, which contains PR #127 and PR #124) in a clean detached worktree:

CI job	Local equivalent	Result
ci (build, vet, lint)	just check	pass
ci (tests)	just test (go test ./... -race)	pass
ci (coverage ≥ 85)	just coverage-check	pass — total 89.5%, no package below floor
docs-validate	go build -o rootline ./cmd/rootline/ && ./rootline validate --all docs/roadmap/	exit 0
installer-tests	sh tests/installers/install-sh-test.sh	exit 0
gitleaks	gitleaks detect	1022 commits scanned, no leaks

Commit hygiene: exactly one commit, subject identical to the PR title, no AI attribution or Co-Authored-By trailer.

This is orchestrator-side verification, not a substitute for the real checks. Once #130 lands and this branch picks up the fixed workflow, GitHub-side checks should appear.