1. create_request dropped its amountless-coercion — amountless requests break three ways

Root cause at electrum/wallet.py:3023: the old amount_sat = amount_sat or 0 +
amount_msat = None if not amount_sat else … is gone, so an empty amount no longer maps
to "amountless".

• (a) crash — QML amountless Lightning request. electrum/gui/qml/qewallet.py:706
  passes amount_msat=amount.msatsInt (= 0 for an empty QEAmount). create_request
  keeps amount_msat=0, so lnworker.create_payment_info raises
  ValueError("amount_msat must not be 0…") at electrum/lnworker.py:2714. createRequest
  only catches InvoiceError (qewallet.py:709) → unhandled exception. This is the standard
  "donation / request-without-amount" flow and it's reachable — with inbound liquidity,
  lightningCanReceive.gt(empty) is true, so the Lightning button is enabled. Master
  produced an amountless invoice here.
• (b) broken — Qt on-chain amountless request. receive_tab.py empty field →
  get_amount() returns None → create_request(amount_sat=None, address=addr) →
  wallet.py:3057 PartialTxOutput.from_address_and_value(addr, None) →
  ValueError: bad txout value: None (reproduced). Caught by the generic except Exception
  and shown as "Error adding payment request"; the request is never created (worked on
  master). Same crash, uncaught, via the add_request RPC with no amount
  (satoshis(None)=None, commands.py:1383).
• (c) wrong — QML on-chain amountless request. qewallet.py:708 passes amount_sat=0
  → amount_msat=0 → Request.get_amount_sat() returns 0 (not None) → a fixed
  0-amount request instead of "any amount".

Fix: re-introduce the coercion in create_request (treat 0/None as amountless:
amount_msat=None, on-chain output value 0).

2. FeerateEdit.setAmount(None) crashes

electrum/gui/qt/amountedit.py:180 — FeerateEdit now subclasses AmountEdit instead of
BTCAmountEdit, losing BTCAmountEdit.setAmount's if amount is None: setText(" ") guard
(amountedit.py:165). AmountEdit.setAmount(None) → to_decimal(None) → Decimal('None')
→ InvalidOperation. confirm_tx_dialog.py:355 and :436 call
self.feerate_e.setAmount(None) whenever there's no fee estimate / not enough funds — a
common path. (fee_e is fine; it's still a BTCAmountEdit.)

🟠 Medium — confirmed wrong output / wire format

3. Qt desktop lists & notification mis-render sub-sat amounts

invoice_list.py:119, request_list.py:149, main_window.py:1375 (the "Payment received"
notification) and :1690 (invoice dialog) now read get_amount_sat_msat_precision() (which
returns a Decimal for sub-sat amounts) but call format_amount(...) without
precision=3. Verified: format_amount(Decimal('1.5')) → rounds to 2 sat ('0.00002'),
and format_amount(Decimal('0.4')) → the malformed string '0.'. So the msat-precision
getter was wired up but the precision is dropped exactly where it should be shown (and
< 0.5 sat renders garbage). Pass precision=3 (as the QML side does).

4. LNURL-pay sends a non-integer amount on the wire

qeinvoice.py:609 computes amount = Decimal(msatsInt)/1000, then
payment_identifier.py:392 does amount_msat = amount_sat * 1000 → Decimal('2345.000'),
sent as params={'amount': …} (:403). aiohttp serializes that to ?amount=2345.000
(trailing zeros). Since BtcField here has msatPrecision: true, any sub-sat amount (or an
LNURL whose min_sendable_msat isn't a whole sat) triggers it, and strict servers doing
int(amount) reject it. Master sent integer msat. Fix: params={'amount': int(amount_msat)}.

5. qefx.satoshiValue stores a Decimal in _amount_msat

qefx.py:164 self._amount.satsInt = v.to_integral_value() (a Decimal); the satsInt
setter multiplies by 1000 and stores the Decimal, so _amount_msat is no longer an int
— violating the invariant the constructor asserts (assert isinstance(amount_msat, int)) and
the 'qint64' property type. Wrap in int(...).

🟡 Low / latent / robustness

6. QEAmount.max/min/lt/gt is_max semantics are wrong (qetypes.py:177):
   gt()/lt() return False whenever either operand is is_max, so max(MAX, normal)
   returns normal (loses MAX) and the result is order-dependent. Latent — no current caller
   passes an is_max amount — but the helper is incorrect for future use.
7. _msat_to_sat truncates toward zero, not floor (qetypes.py:54,
   int(Decimal(msat)/1000)): inconsistent with // 1000 used everywhere else in the
   codebase; off-by-1-sat for negative sub-sat LN amounts (reachable via
   qetransactionlistmodel.py where amount_msat < 0).
8. __eq__ against an int silently changed from sat to msat and the str branch was
   removed (qetypes.py:192). No broken caller found (comparisons are all against 0), but
   amount == <nonzero int> now means msat — a footgun worth a comment or an explicit
   msat-named helper.
9. assert used to validate untrusted input: lnurl.py:188 validates a remote server's
   min/max withdrawable with assert, and the QEAmount constructor asserts its args — both
   stripped under python -O, letting malformed LNURL ranges / bad amounts through.
   (Pre-existing pattern, but now on the canonical msat path.)
10. formatMilliSatsForEditing lacks the None guard its siblings formatSats /
    formatMilliSats have (qeconfig.py:364).
11. positive uses >= 0 (was > 0) (qetypes.py:110): a zero-value entry is labeled
    received/credit in LightningPaymentDetails.qml:55 / TxDetails.qml:110 (mostly hidden
    by visibility guards).
12. min/max return shared references → effectiveMaxWithdrawable can alias the live
    wallet QEAmount in LnurlWithdrawRequestDialog.qml; self-corrected by updateLimits()
    but fragile. Minor: ChannelBar.qml switched to .satsInt, truncating msat in bar-width
    math (cosmetic).