feat(payout): log amount, asset and chain per escalated payout order

[TaprootFreak]

When processFailedOrders parks orders in PayoutUncertain, logFailedOrders wrote a single collecting line for the whole batch:

N payout order(s) failed and pending investigation: [Order ID: …, Context: …, CorrelationID: …] ,[Order ID: …, …] ,...

Two problems with that as the only record:

1. It does not say what is at stake. Amount, asset and chain — the fields that decide how urgent an escalation is — are only in the DB, so judging one always meant a lookup.
2. Only one order per line is machine-readable. A regexp matches a line once, so log-based monitoring extracts the first order of a batch and silently drops the rest.

Change

One line per escalated order, in addition to the unchanged collecting line:

Payout order 4711 escalated to PayoutUncertain: amount 0.31000703 of "XMR" on chain Monero, context BuyCrypto, correlation "4242"

The collecting line is deliberately left alone — processFailedOrders passes its return value to createMailRequest, which puts it into the escalation mail.

Field choice: amount and chain are non-nullable columns on the entity and always populated; asset is a nullable eager relation and degrades to unknown.

Parsing contract

The wording is an interface, not prose. amount is numeric and chain/context are enums, so a literal fence holds for them by construction.

The free-form values — the asset name and the correlation id — are JSON-encoded, and that is a deliberate choice over fencing them with a plain quote. A plain quote is forgeable in both reading directions, and each direction closes one hole while opening the other:

• read up to the first quote, and a name like Foo" on chain Ethereum closes its own field and imitates the next fence;
• read up to the last one, and a later free-form field can offer a competing fence instead.

A newline is worse still: it splits the record in two, and the second line can spell out a complete, invented escalation with a freely chosen chain and amount. Both quote cases produce a wrong chain with no parse error at all — a silently wrong value in a critical alert, which is worse than a loud failure. Both were measured rather than argued. The ambiguity is in the format, not in the quantifier: a closing quote is not identifiable while the value may contain one. JSON encoding removes the class instead of moving it — a quote inside a value arrives escaped, and the reader skips escape pairs with (?:[^"\\]|\\.)*.

The fallback uses ||, not ??: an empty name would otherwise encode to "" and read back as an empty asset rather than as a name. (CONTRIBUTING.md prefers ??; this is the documented exception, and the || 'fallback' form has precedent in the codebase, e.g. blockchain-transaction.service.ts.)

Verification

• payout-log.service.spec.ts — 14 tests, including the two adversarial cases above (a name carrying a quote plus a forged fence, and a correlation id carrying a full forged tail), a backslash in both free-form fields and an even run of backslashes ahead of an embedded quote, and a newline (the escape mechanism, its parity, and control characters — each verified by mutation: the matching faulty encoder fails that one test and no other), plus a missing asset relation, an empty name, a name with a space, a name with an apostrophe, and a batch with differing chains/assets
• full payout suite: 31 suites / 659 tests green
• tsc --noEmit and eslint clean

Deploy note

A monitoring rule in the infrastructure config is being switched onto this line. It must go live after this release, not before — otherwise it watches for a line nobody writes yet.

[TaprootFreak]

Ten review passes to zero findings (two parallel reviews per pass: conformance and logic).

What the passes actually changed, worst first:

1. The field fence was forgeable, and fixing it once was not enough. A plain quote around a free-form value can be read two ways, and each way closes one hole while opening the other — stop at the first quote and an asset name closes its own field to imitate the next fence; stop at the last one and a later free-form field (the correlation id) offers a competing fence. Both yield a wrong chain with no parse error at all. Both were reproduced, not argued. The ambiguity was in the format, not in the quantifier, so the format changed: the free-form values are JSON-encoded and read as JSON strings.
2. A newline would not have mis-parsed the record — it would have forged one. An encoder that handles quote and backslash but leaves control characters alone splits the line in two, and the second half can spell out a complete, invented escalation with a freely chosen chain and amount.
3. Test gaps found by mutation rather than by reading. A single backslash did not pin the escape mechanism: an encoder doubling only the first one passed every test while leaving the line forgeable. Each adversarial test is now verified by patching in the matching faulty encoder and confirming that this one test — and no other — fails.

Two reported findings were rejected with evidence instead of being applied. The more interesting one: JSON.stringify does not escape U+2028/U+2029, which was reported as the same forgery class. Measured, the record carries no 0x0A/0x0D, wc -l and grep count it as one line, and the pattern still reads the real chain — the line-based pipeline does not split there, so a viewer may wrap it visually but the alert is unaffected.

Verification: 14 tests in payout-log.service.spec.ts, full payout suite 31 suites / 659 tests, tsc --noEmit, eslint and prettier --check clean, all 12 CI checks green on the head commit.