feat(arap): terms, numbers and line accounts in the core (P4b S4.1)

Documents could name only one revenue or general-expenses account per
project, had no number of their own, and took a due date the caller had
to work out. This slice gives the core the pieces the rest of S4 needs,
and journals nothing: an old-shape document still writes byte for byte,
so the owner's books need no upgrade for it.

- Payment terms (B-39): Net n, Net n EOM, due on receipt and a custom
  date, with the early-payment discount and its exact bound
  (kernel::discount_max, Kani + bridge). A due date past the calendar's
  end is refused, never a panic, and a discount is refused with terms
  that have no net days.
- Invoice numbers (B-40, A-2): first_number plus the count of numbered
  invoices, zero-padded to four digits and wider past 9,999, stored at
  issue, kept by a void; legacy invoices are uncounted.
- Line accounts (A-10): a document line may name its account, and the
  entry posts one line per (account, project) part. An invoice line takes
  revenue or a liability holding no role (deferred revenue); a bill line
  an expense or a non-cash asset holding no role. Roles, cash accounts
  and headers are refused.
- A line's amount is exactly its quantity times its unit price
  (kernel::line_amount, Kani + bridge): both or neither, never rounded.
- A vendor's invoice number names one standing bill per vendor, with
  case, spaces and hyphens ignored, unless a duplicate reason says why
  (B-40).
- The record fields S4.3 will journal: number, terms, bill-to and seller
  snapshots, customer reference, memo, the empty sends list S5 fills, and
  the bill's received_on, all optional and defaulted.

The store refuses a line carrying an account, quantity or unit price
before it rehearses or journals anything: those fields are journaled from
S4.3's documents_v2 on, and I-3 will not let a public write replay
without them. `document_line_fields_wait_for_documents_v2` proves the
refusal, the unchanged journal and allocators, and that an ordinary line
journals exactly as before. S4.3 removes this guard in the same change
that journals the fields and adds its byte-for-byte test.

The document commands keep their signatures; create_invoice_with and
create_bill_with take the optional fields for S4.3 and for tests. They
are the existing issue commands with more fields, not a new state
transition, so no Lean Step is added. Kani: line_amount_is_exact runs in
`just prove`; discount_max_is_bounded relates a product to a quotient and
runs in `prove-slow` (163 s), as the proration charge harnesses do.

just check green; just prove green.

crates/ledger-core/tests/kernel_bridge.rs

@@ -484,4 +484,53 @@ proptest! {
             prop_assert_eq!(i.built_in_gain_704c.map(dec), d.built_in_gain_704c);
         }
     }
+
+    /// kernel::discount_max at i64 (what Kani's discount_max_is_bounded
+    /// proved) and at Decimal agree where both are exact: the bound is
+    /// the same money, never above the total, and result x 10,000 =
+    /// total x basis points on both.
+    #[test]
+    fn discount_max_agrees(
+        total in 0..=MAX_CENTS,
+        percent_bp in 1u32..=9_999,
+    ) {
+        let narrow = kernel::discount_max(total, percent_bp);
+        let wide = kernel::discount_max(dec(total), percent_bp)
+            .expect("a decimal division by 10,000 is exact");
+        if let Some(n) = narrow {
+            prop_assert_eq!(wide, dec(n));
+        }
+        prop_assert!(wide >= Decimal::ZERO);
+        prop_assert!(wide <= dec(total));
+        prop_assert_eq!(
+            wide * Decimal::from(10_000u32),
+            dec(total) * Decimal::from(percent_bp)
+        );
+    }
+
+    /// The discount bound Kani proves at i32 (small totals) is the same
+    /// bound at i64, which the property above carries to Decimal.
+    #[test]
+    fn discount_max_i32_agrees_with_i64(
+        total in 0i32..=200_000,
+        percent_bp in 1u32..=9_999,
+    ) {
+        prop_assert_eq!(
+            kernel::discount_max(total, percent_bp).map(i64::from),
+            kernel::discount_max(i64::from(total), percent_bp)
+        );
+    }
+
+    /// kernel::line_amount at i64 (what Kani's line_amount_is_exact
+    /// proved) and at Decimal agree: cents x cents at i64 is the same
+    /// product as dollars x dollars at Decimal, to four places.
+    #[test]
+    fn line_amount_agrees(
+        quantity in 0..=1_000_000i64,
+        unit_price in 0..=1_000_000i64,
+    ) {
+        let narrow = kernel::line_amount(quantity, unit_price);
+        let wide = kernel::line_amount(dec(quantity), dec(unit_price));
+        prop_assert_eq!(narrow.map(|n| Decimal::new(n, 4)), wide);
+    }
 }