fix(booking): stop padding a balance on the pad's own date - #2187

Review find on #2187. Sweeping the pad scenarios against beancount turned
up a second broken case, worse than the reported one: a pad written after
a balance on the same date, serving a LATER balance.

    2024-06-15 balance Assets:A   0.00 USD
    2024-06-15 pad     Assets:A   Equity:O
    2024-07-01 balance Assets:A  50.00 USD

bean-check accepts that file. On main the account came back with NO
balance at all and `check` reported nothing -- silently empty rather than
silently wrong. The same-date balance consumed the pad, so the later
assertion had nothing left.

The fix already covers it, because Balance now precedes Pad and the pad
stays pending. This adds the test.

Both halves of the fix are confirmed by mutation: restoring
Pad-before-Balance fails two tests, restoring the date-only sort in
`process_pads` fails one.

Review find on #2187. The issue explicitly left the FFI path unverified,
noting that `expand_pads` runs its own date-only sort and could diverge
from the CLI either way. Nothing there covered the case: the existing
`SAME_DATE_LEDGER` shares a date between a pad and an UNRELATED
transaction, with the balance a day later.

It is correct -- `expand_pads` gets its pads from `process_pads`, which
this branch fixed, so the decision is shared rather than duplicated --
but that was unverified rather than untrue. Now asserted, and confirmed
to fail when Pad-before-Balance is restored.

The date-only sort at the top of `expand_pads` is left alone. It orders
the OUTPUT pairs, not the pad decision, and changing it would reorder
same-date directives on the FFI path only. Whether the two paths should
share an ordering rule is worth deciding on its own, not as a rider here.

The parse-side pin added with the blank-line fix covers what
`ParsedLedgerPayload` holds. `LedgerPayload` holds something else: the
output of the shared `process()` pipeline, sorted by
`canonical_sort_key` and booked.

That gap is not hypothetical. #2187 swaps `DirectivePriority` for `Pad`
and `Balance`, which reorders a cached ledger without changing a single
parsed directive -- the parse-side digest does not move, and a v16 blob
would deserialize into an order that build no longer produces.

The fixture puts a pad and a balance on the same date on purpose: that
pair is the one whose relative order the priorities decide, and on
different dates the date component of the sort key settles it and a
priority swap changes nothing. Verified by applying #2187's swap, which
fails this test and passes the parse-side one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012nNGPA44Dt32NyxWem26xr

Review find on #2187. Sweeping the pad scenarios against beancount turned
up a second broken case, worse than the reported one: a pad written after
a balance on the same date, serving a LATER balance.

    2024-06-15 balance Assets:A   0.00 USD
    2024-06-15 pad     Assets:A   Equity:O
    2024-07-01 balance Assets:A  50.00 USD

bean-check accepts that file. On main the account came back with NO
balance at all and `check` reported nothing -- silently empty rather than
silently wrong. The same-date balance consumed the pad, so the later
assertion had nothing left.

The fix already covers it, because Balance now precedes Pad and the pad
stays pending. This adds the test.

Both halves of the fix are confirmed by mutation: restoring
Pad-before-Balance fails two tests, restoring the date-only sort in
`process_pads` fails one.

Review find on #2187. The issue explicitly left the FFI path unverified,
noting that `expand_pads` runs its own date-only sort and could diverge
from the CLI either way. Nothing there covered the case: the existing
`SAME_DATE_LEDGER` shares a date between a pad and an UNRELATED
transaction, with the balance a day later.

It is correct -- `expand_pads` gets its pads from `process_pads`, which
this branch fixed, so the decision is shared rather than duplicated --
but that was unverified rather than untrue. Now asserted, and confirmed
to fail when Pad-before-Balance is restored.

The date-only sort at the top of `expand_pads` is left alone. It orders
the OUTPUT pairs, not the pad decision, and changing it would reorder
same-date directives on the FFI path only. Whether the two paths should
share an ordering rule is worth deciding on its own, not as a rider here.

* fix(parser): a blank line no longer eats a directive's tags

`convert_note` and `convert_document` collected the `#tag` / `^link`
tokens on the header line by walking the node's direct tokens and
breaking at the first NEWLINE. A directive node begins with the trivia
that precedes it, so when a blank line sits above the directive its
first token is a NEWLINE and the loop broke before reaching anything --
every tag and link dropped.

That is the common case, not a corner: a blank line between directives
is how ledgers are normally written. Of the three tagged `document`
directives in the compatibility corpus, two lost their tags and one
kept them, the one written directly under another directive.

`document` has had this since long before `note` had any tags to lose,
and nothing caught it because every fixture placed the directive
immediately after another one. The completion test added here made the
same mistake first and passed while the bug was live; its fixture now
has the blank line that makes it real.

Both directives now share `header_tags_and_links`, which starts
collecting only once the header's STRING has been seen and breaks on
the newline after it.

Cache versions move because parser OUTPUT changed: loader 31 -> 32, and
wasm 15 -> 16. The wasm bump is overdue -- #2160 moved the loader
version and the pin and left this one at 15, so v15 is now ambiguous
between the old and new `ArchivedNote` shapes and every v15 blob has to
be rejected.

That miss is why `directive_archived_form_is_pinned` exists. The
version pin can only force a question; it cannot tell a loader-internal
change from one that moves our archived directives, and on #2160 the
question got the wrong answer with every test still passing. The new
test hashes the archived bytes of one of every directive kind, so a
layout change and an output change both fail it. Verified against both:
reverting this parser fix and swapping `Note`'s two field declarations
each move the digest.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012nNGPA44Dt32NyxWem26xr

* test(wasm): pin the processed ledger the cache actually archives

The parse-side pin added with the blank-line fix covers what
`ParsedLedgerPayload` holds. `LedgerPayload` holds something else: the
output of the shared `process()` pipeline, sorted by
`canonical_sort_key` and booked.

That gap is not hypothetical. #2187 swaps `DirectivePriority` for `Pad`
and `Balance`, which reorders a cached ledger without changing a single
parsed directive -- the parse-side digest does not move, and a v16 blob
would deserialize into an order that build no longer produces.

The fixture puts a pad and a balance on the same date on purpose: that
pair is the one whose relative order the priorities decide, and on
different dates the date component of the sort key settles it and a
priority swap changes nothing. Verified by applying #2187's swap, which
fails this test and passes the parse-side one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012nNGPA44Dt32NyxWem26xr

* docs(parser): correct the rule the tag-collection comments state

Both call sites still described stopping "at the first NEWLINE" as the
thing that captures the header, which is the bug the commit before this
one removed. They now point at `header_tags_and_links`, which is where
the rule lives.

Also records that the formatter already guarded its header walks on a
`seen_content` flag for exactly this reason. The converter was the
outlier, not the pioneer.

---------

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

Four PRs shipped user-visible behavior changes without an entry: the
two formatter tag losses (#2192), the blank-line tag drop (#2189), the
same-date pad (#2187), and this branch's tolerance grammar (#2195).

The changelog already carries the direct sibling of the first one --
"`rledger format` no longer deletes a posting's currency, cost or price
when it has no units number" (#2142) -- so the omission was mine, not a
question of whether this class belongs here.

Each entry records the cache versions that moved with it, which is the
part a reader upgrading actually needs and the part not recoverable from
the diff.

* fix(parser): a balance tolerance may follow an arithmetic amount

`directive_arithmetic_value` scanned to the first top-level CURRENCY and
treated everything before it as the amount expression. With no currency
between the amount and the tolerance, that swallowed the tolerance:
`0.25 + 0.75 ~ 0.01 USD` was handed to the expression parser as
`0.25 + 0.75 ~ 0.01`, which is not arithmetic, so the whole value was
reported malformed.

Only the currency-less arithmetic form reached that state. With a
currency after the expression the scan stopped there and parsed, which
is why `100.00 ~ 0.01 USD` and `0.25 + 0.75 USD ~ 0.01 USD` both worked
and `0.25 + 0.75 ~ 0.01 USD` did not. `~` now ends the expression, which
is what it means; the tolerance is read separately as it always was.

This is what made `rledger format` emit a balance that no longer parses
(#2191): the formatter emits the single-trailing-currency form, which
is the beancount form and the one the parser already accepted for a
plain number.

Tested for VALUES, not just for parsing. An earlier bug in this same
scan fell back to "take the first NUMBER" and turned `(1 + 5) / 2.1`
into a silent assertion against 1 -- parsed cleanly, asserted the wrong
thing -- so each of the seven accepted forms is checked against the
amount it should evaluate to, with a ledger holding 0.25 confirming that
`0.25 + 0.75` does not match it.

Brings in the matrix-wide format-fidelity harness that #2192 could not
land: it fails on `balance_with_arithmetic_and_tolerance` without this
fix, which is how the bug was found.

Closes #2191

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012nNGPA44Dt32NyxWem26xr

* fix(parser): a price rejects a tolerance instead of discarding it

Review of the commit before this one caught a regression it introduced.
`directive_arithmetic_value` is shared by `balance` and `price`, so
making `~` end the amount expression applied to both -- and a price has
no tolerance. `price USD 1.10 + 0.05 ~ 0.01 EUR` went from a
malformed-value error to silently evaluating 1.15 and dropping the
tolerance on the floor. Trading a diagnosed error for a silent
half-reading of the author's input is a bad trade.

`ToleranceForm` now says which grammar is being parsed: `balance` stops
at `~`, `price` does not.

That restores the old handling of the arithmetic form and leaves the
plain one, `price USD 1.10 ~ 0.01 EUR`, which main ALREADY accepted the
same silent way -- `~` is not an arithmetic operator, so the scan took
the fast path and fell back to the first NUMBER, yielding 1.10 with the
rest discarded. Fixing only the half I broke would leave the identical
silent truncation one keystroke away, so a top-level `~` on a price is
now diagnosed outright.

Both forms are covered, and so are the three tolerance-free price forms
with the values they must evaluate to -- an error path that also stopped
accepting valid input would pass a test that only asserted rejection.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012nNGPA44Dt32NyxWem26xr

* test(format): raise the round-trip floor to what actually round-trips

The fidelity harness guards against going quiet by asserting a minimum
number of fixtures reached the comparison. `> 20` was a third of the way
down from the real figure: 37 of the 42 fixtures round-trip today, the
other 5 being error fixtures, so ten could start failing to parse and be
skipped without the floor noticing. Skipping is exactly how this test
would go quiet.

Measured rather than guessed, and set just under the measured value so
adding fixtures does not churn it.

* test(parser): census which directives keep tags and which refuse them

The failure this session kept turning up is a third state between the
two: accept the tag, then drop it because the model has nowhere to put
it. `note` was in it (#2160), both formatters were in it (#2184), and a
price's tolerance was in it.

So this counts the directives rather than testing one. Seven refuse,
three keep, and each refusal is checked against its tag-free form too --
a rejection that also rejected valid input would satisfy an
assertion that only looked for an error.

`query` is in neither set: it accepts a tag and discards it. That is
asserted here as CURRENT behavior, not as correct behavior. Which way it
should go needs `bean-check` (beancount's `Query` has no tags field,
which argues for refusing; a parser-lima corpus file uses the form,
which argues it appears in the wild) and the container is not built
here. Filed as #2194. Written as an assertion so the day it changes this
fails and the census gets updated rather than quietly going stale.

I implemented the refusal and backed it out: it makes
`parser-lima/examples_data_full.beancount` error, and an unverifiable
strictness increase does not belong in a PR about tolerance parsing.

* chore(cache): bump the versions the tolerance changes invalidate

Loader 32 -> 33, wasm 17 -> 18, pin 33.

Parser OUTPUT moves in both directions here, which is why both caches
have to: a v32/v17 blob holds a parse error where this build now
produces a balance directive, and holds a silently truncated 1.10 where
this build now produces an error. Either way the cache would serve a
reading the binary no longer agrees with.

Both `CostNumber` and `MetaValue` fixture tripwires move version only --
balance and price amounts are `Decimal`s on the directive and take part
in neither archived layout, and the assertions after each comment prove
that rather than take the comment's word for it.

* fix(parser): a child node no longer stops the tilde scan

Review feedback on #2192 was that `emit_header_tags_and_links` bailed
out of its walk at the first child NODE, so it did not scan the whole
header. I fixed that there and then wrote `has_top_level_tilde` with the
identical `break` a few hours later.

Harmless today for the same reason it was harmless there -- a price's
only child node is a META_ENTRY, whose tokens are not direct children,
so nothing here can see a `~` written inside metadata. But a header that
ever gains a child node would stop being scanned at all, and the whole
point of this function is to refuse a tolerance rather than skip past
one.

Also records a blind spot in the format-fidelity test, found while
checking whether the tolerance clause is validated at all (it is not,
#2193): a model comparison cannot see data the model never held. `balance
X 1.00 USD ~ 0.01 EUR` formats to `1.00 ~ 0.01 USD`, erasing the EUR
from the file, and the test passes -- both sides lost it in the parser.
Which is exactly why the note-tag test also asserts on output text.

* test(parser): match the price-tolerance error on its kind, not its Debug

Review feedback: the assertion stringified the whole `ParseError` with
`{e:?}` and searched that. Debug output carries the span and context
fields too, so the test was coupled to formatting it does not care
about.

It now matches `ParseErrorKind::SyntaxError(m)` and searches `m`, which
is the part the test is actually about. Still pins the wording --
rewording the message fails it -- so this narrows what the assertion is
brittle to rather than weakening it.

* docs: record this run's fixes in the changelog

Four PRs shipped user-visible behavior changes without an entry: the
two formatter tag losses (#2192), the blank-line tag drop (#2189), the
same-date pad (#2187), and this branch's tolerance grammar (#2195).

The changelog already carries the direct sibling of the first one --
"`rledger format` no longer deletes a posting's currency, cost or price
when it has no units number" (#2142) -- so the omission was mine, not a
question of whether this class belongs here.

Each entry records the cache versions that moved with it, which is the
part a reader upgrading actually needs and the part not recoverable from
the diff.

---------

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