docs(skills): name flow-filter-token-unknown for the flow-node filter position (#16803)

The passage sat directly after "A flow node's `config.filter` takes these
tokens too", so its rule id read as the one that fails an unknown token in a
flow node. Since #16732 that position is owned by a second rule.

The two ids stay distinct, because the two positions do not share a token
vocabulary or a consequence:

  - flows -> `flow-filter-token-unknown` (validate-flow-filter-tokens.ts),
    which fires only when NEITHER dialect resolves the token and whose
    consequence is a guard refusal: "this node cannot run at all";
  - dashboards/objects/views/reports/datasets/pages/apps ->
    `filter-token-unknown` (validate-filter-tokens.ts), which deliberately
    does not walk `flows` and whose consequence is the silent zero.

Collapsing them into one statement would re-teach the confusion the split
exists to prevent, so the flow sentence names its own rule and the general
paragraph is scoped with "Outside a flow".

Wording (not the id distinction) was tightened to stay under the published
token ratchet: 2136 -> 2146 tokens against a 2149 ceiling.


Claude-Session: https://claude.ai/code/session_01P58euzUXCVJNwmhuPC9DXY

Co-authored-by: Claude <noreply@anthropic.com>

Author: hotlong

skills/objectstack-query/rules/filters.md

@@ -227,23 +227,24 @@ ObjectQL read AND write paths (`find`/`findOne`/`count`/`aggregate`/`update`/
 strings and concrete ids. So use tokens in a hand-issued engine query too:
 computing "today" at module load freezes the date into the built artifact.
 
-A **flow node's** `config.filter` takes these tokens too. What happens when one
-of them drops a condition is a flow rule, not a query rule:
-**objectstack-automation** — a dropped condition *widens* the query, so
-`get_record` / `update_record` / `delete_record` fail the step instead of
-running it.
-
-**Unknown tokens are rejected, not ignored.** A value that is entirely `{...}`
-is a placeholder by construction: `objectstack build` fails it (rule
+A **flow node's** `config.filter` takes these tokens too. What a dropped
+condition does there is a flow rule, not a query rule
+(**objectstack-automation**): it *widens* the query, so `get_record` /
+`update_record` / `delete_record` fail the step instead of running it. A
+`{FUNC()}` neither dialect resolves is `flow-filter-token-unknown`: that node
+cannot run at all.
+
+**Unknown tokens are rejected, not ignored.** Outside a flow, a whole-`{...}`
+value is a placeholder by construction: `objectstack build` fails it (rule
 `filter-token-unknown`) and the resolver throws — because an unresolved token
 reaches SQL as a **literal**, matches nothing, and renders a widget showing 0,
 indistinguishable from "there is no data". Near-misses, not tokens:
 `{current_user}` (the RLS expression root), `{this_quarter_start}`, `{user_id}`
 (a real `titleFormat` interpolation) and `{organization_id}` (the column name);
 the error names the correction. A value that merely *contains* braces is left
-untouched — `'user-{current_user_id}'` is a literal. Check a spelling while
-authoring with `isDateMacroToken(tok)` / `isContextToken(tok)` from
-`@objectstack/spec/data`, passing the token WITHOUT braces.
+untouched — `'user-{current_user_id}'` is a literal. Check a spelling with
+`isDateMacroToken(tok)` / `isContextToken(tok)` from `@objectstack/spec/data`,
+WITHOUT braces.
 
 **`*_end` is a calendar DAY.** `{current_year_end}` is `2026-12-31`, so on a
 `datetime` column `<= {current_year_end}` stops at midnight on the 31st. Use