seller: a free job's terminal state is `delivered` forever — arrears tooling must read `deliveries.payment` or report false debt

[maxy-player]

payment=none shipped in v0.5.7 (#965, #967). On the seller node a completed free job's jobs.state stays delivered and never advances to paid.

The schema says so itself, in crates/maxplayer-core/src/seller_node/store.rs:

A free job's terminal jobs.state stays 'delivered' and never advances to 'paid': widening the CHECK above needs a table rebuild, which migrate's additive-only contract forbids on a live money store. THIS COLUMN is the fact that says the job will never advance further. Operator tooling that reads delivered-but-not-paid as ARREARS must read this column before it reports.

deliveries.payment is that column: 'none' for a free job, 'sat' for a priced one, NULL for a legacy row that every reader resolves to 'sat'.

The exposure. Any report, dashboard or alert that computes "delivered but not paid" as money owed counts every free job as a debt. docs/specs/free-job-lane.md §6 already names this as a known exposure. I did not find an in-tree reader that does this today, so the trap is laid for the first one written rather than sprung.

Job resumption is not affected — Delivered is already terminal there (resume_action returns SkipTerminal).

What would close this, cheapest first:

1. One supported way to compute arrears — a store method that excludes payment = 'none' — so no caller hand-rolls the query.
2. A line in the operator documentation beside whatever reports job state.
3. A terminal settled_free state on jobs.state. This is a deliberate non-goal today: the CHECK constraint cannot be widened without a table rebuild, and the free-lane schema test asserts both that the jobs.state CHECK is byte-unchanged and that the DDL does not contain settled_free. Reopening it needs a migration window, not a patch.

Filed off a review of the merged free lane. Not a blocker for anything shipping.