feat(okf): a flow sequence of plain scalars parses, and the corpus number is 6/53

`tags: [a, b, c]` is the form SPEC.md 4.1's own frontmatter skeleton writes out,
and 9/53 upstream reference concepts use it. It raised on the `[` indicator.
It parses now, to the same list its block-sequence sibling already produced.

The predicate is character-level, inside `_parse_flow_sequence`: an element is a
plain scalar only if it is non-empty and carries none of `{ } [ ] : , " ' #`,
and it then passes the unchanged scalar-indicator rule. Everything that would
need YAML semantics to split or unquote still raises - a quoted element (quotes
are retained here, never stripped), a colon or comma inside an element, a
sequence inside a sequence, an empty element, an anchor, an alias. A sequence
may not mix scalars and mappings, the rule the block list already carries, and
the mixing verdict is reached before the element is parsed so the caller is told
about the mix rather than about a key the allowlist would have named instead.
The 1.3.0 `sources` flow-mapping carrier is unchanged and pinned against
regression. Depth 1 is not spent: the elements are leaves.

Measured with the denominator, against the pinned corpus (`_okf-upstream` @
3fcbb9f, 53 non-reserved documents) and the pinned SPEC (`_okf-canonical` @
ad30107). Baseline reproduced first, with a known-positive control, at 0/53.
After: 6/53, all six in acme_retail. It does not close the corpus - 44/53 still
stop on `generated` written as a top-level block mapping, which spends the
no-nesting-past-depth-1 rule and is a security decision, out of scope here.

P1 alone, per the operator decision of 08.09. The two neighbouring predicates
were measured and deliberately not built: a flush-left block sequence and a
folded plain scalar release 0/53 each on their own, and stacked on this one they
still measure 6/53. `_consume_block_list`, the `description` continuation and
the allowlist are untouched.

docs/LIMITATIONS.md's tags/description entry is rewritten against the
measurement: three of its claims were wrong. The parser does have a
sequence-value type (since 1.3.0 - what it lacks is the indentation the corpus
omits); the figure is 6/53, not the 1.2.0-era 4/53; and tags/description are
not the residual that blocks the corpus. README gains the sequence carrier in
the paragraph that already describes the mapping one.

Self-safety: the predicate compiles no regex, so docs/redos-sweep.py cannot see
it. Measured instead on the CPU clock - linear in element length (exponent
0.86-0.99) and in element count (0.97-1.05) over four doublings to 800_000 -
and pinned by two bounds in tests/test_okf.py.

Six rows that pinned the old refusal are re-aimed at the class that still
holds - the quoted element - the way the 1.3.0 rows were when the carrier
opened. One of them lives in src/llm_ingestion_guard/coverage.py, which is why
the src diff is three files rather than one.

Version 1.4.0 in the code only. The CHANGELOG entry stays under Unreleased and
no tag is cut: README's badge and install pin must keep naming a tag that
exists.

Gates after `git add`: 893 passed (was 868), coverage 130/130 + 6/6 gaps,
redos-sweep exit 0, LIMITATIONS still 45 entries.

docs/LIMITATIONS.md

@@ -123,24 +123,42 @@ items; this is the full list, each with the mechanism.
   exported for exactly that. The dangling-or-substituted `executor`/`attester`
   pointer question stays out of reach separately: both are top-level block
   mappings, a carrier that is still refused.
-- **`tags` and `description` block the OKF import corpus universally, before the
-  trust layer is even reached.** The line-flat frontmatter parser has no
-  sequence-value type at all: `tags` is present in 53/53 upstream concept
-  documents — 9/53 as a flow sequence (`[a, b, c]`, rejected on the `[`
-  indicator) and 44/53 as a block sequence (`- a` / `- b`, rejected as
-  `"malformed frontmatter line"`) — 100% rejection regardless of form.
-  `description` is present in 53/53; 29/53 is a folded plain scalar continuing
-  on an indented second line, which the parser has no continuation-line model
-  for and misreads as `"nested mappings are not supported"` (the remaining
-  24/53 are single-line and parse fine). Measured directly on the upstream
-  reference bundles (`_okf-upstream/okf` @ `3fcbb9f`): removing `tags` alone
-  lets 4/53 documents pass; removing both `tags` and `description` together
-  (trust layer untouched) lets the same 4/53 pass, and all four then parse
-  `generated` correctly as a mapping. **Independent of the mapping-form work
-  above:** neither `1.2.0`'s flow mapping nor `1.3.0`'s `sources` carriers move
-  anything on this corpus, because `tags`/`description` reject before `sources`
-  is ever read. No sequence-value type or continuation-line model exists in the
-  stdlib-only parser to close this with.
+- **`tags` parses in two of the three forms the OKF corpus writes it in;
+  `description`'s folded form still does not — and neither is what caps the
+  corpus.** Re-measured 2026-09-07/08 against the pinned upstream reference
+  bundles (`_okf-upstream/okf` @ `3fcbb9f`, denominator **53** — every
+  non-reserved `.md`, which is SPEC §11.1's own unit) and the pinned SPEC
+  (`_okf-canonical` @ `ad30107`). This entry carried three claims that the
+  measurement showed to be wrong, all three inherited from `1.2.0` and left
+  standing for twelve days after `1.3.0` moved them; they are corrected here.
+  - **A sequence-value type exists** — `_consume_block_list` has parsed block
+    lists of plain scalars since `1.3.0`, and `1.4.0` adds the flow sequence of
+    plain scalars (`tags: [a, b, c]`, SPEC §4.1's own skeleton). What is missing
+    is not the type but the **indentation requirement**: `_consume_block_list`
+    demands a leading space, and the corpus writes `- a` flush at column 0
+    (36/53 of `tags`, 44/53 of `sources`). Shape census of `tags` over the 53:
+    36/53 flush block sequence, 9/53 flow sequence, 8/53 single-line scalar.
+  - **The number is 6/53, not 4/53.** `4` was the `1.2.0` parser's figure.
+    Measured on `1.4.0`, the corpus goes from **0/53 to 6/53** — all six in
+    `acme_retail`, being 6 of the 9 documents whose `tags` is a flow sequence;
+    the other three stop on the mapping-key allowlist (`parameters.name` ×2,
+    `not.term` ×1), not on `tags`.
+  - **`tags`/`description` are not the binding constraint.** `description`
+    alone releases **0/53** — 29/53 write it as a folded plain scalar over an
+    indented second line, which the parser has no continuation-line model for,
+    but removing that obstacle by itself lets nothing through. With all three
+    surface forms closed the corpus still measures **6/53**, because **44/53
+    stop on `generated` written as a top-level block mapping**, and behind that
+    wall sit 44/53 single-quoted scalars inside the mapping. That constraint is
+    refused deliberately: it spends the no-nesting-past-depth-1 rule, which is
+    a security decision and not a parser detail.
+  **Said plainly: `1.4.0` takes this corpus to 6/53, not to 53/53.** The two
+  neighbouring predicates were measured and deliberately **not** built — a
+  flush-left block sequence and a folded plain scalar each release **0/53** on
+  their own, and stacked on top of `1.4.0` they still measure 6/53. They would
+  cost parser surface and buy no measured conformance. The full measurement,
+  including the SPEC quotations and the per-candidate table, is
+  `docs/2026-09-07-limitations-44-maaling.md`.
 - **A persist gate cannot cover execution risk.** OKF v0.2 introduces concepts whose
   purpose is to *name code to be run* (`runtime`, `executor.resource`,
   `attester.resource`). This library answers "is this safe to **store**"; executable