Surface maxWithdrawableSats on the payouts page (#802)

* Plumb maxWithdrawableSats through balance + autopayout

`getBalanceFromNode` already decodes maxWithdrawableSats off the WS
contract, but `getBalanceFromApp` was throwing it away and returning
just the raw number. Forward both fields so the dashboard action and
the autopayout workflow can use the node-side estimator.

The estimator nets out routing-fee headroom at the source. When
present, autopayout sends maxWithdrawableSats verbatim.

Pre-MDK-883 merchants and the legacy HTTP /balance fallback both
surface maxWithdrawableSats=null. Skipping on null would silently
disable autopayout for every deployed merchant until they upgrade, so
the workflow falls back to `balanceSats * 0.99` when the field isn't
populated. Once every merchant runs an SDK that fills it in,
FEE_RESERVE_FRACTION can go away.

* Render maxWithdrawableSats on payouts page

The dashboard headlined raw channel balance, which overstates what can
actually flow out. Lightning needs routing-fee headroom, and merchants
would hit payout failures when they tried to send the full number on
screen.

When the merchant SDK reports a max-sendable estimate, the balance card
keeps the total balance as the headline and adds "{max} sats available
to withdraw" beneath it, so both numbers are on screen together. An
info icon next to the label explains why they differ. A "Send max"
button on the amount input prefills the node-side estimate.

Three render states cover what `maxWithdrawableSats` can carry:
  null  -> headline-only balance, no secondary, no tooltip, no "Send
           max" button. Identical to the legacy behaviour.
  0     -> balance headline, "0 sats available to withdraw" below,
           no "Send max" button, tooltip explains the routing-fee
           floor.
  > 0   -> balance headline, "{max} available to withdraw" below,
           "Send max" button prefills the estimate, tooltip explains
           the routing-fee headroom.

The `null` branch is the legacy/pre-upgrade fallback. Merchants on
older SDKs and the HTTP /balance compatibility path don't populate the
field, so their dashboard is the same as before. The
tooltip, secondary line, and Send max button only appear once the
merchant ships an SDK build that returns the estimate.

Balance and maxWithdrawable share one state slot because they always
come from the same server snapshot. Splitting them would let them
drift across re-fetches.

The tooltip copy avoids quoting a specific fee percentage on purpose.
The current node-side estimate happens to reserve ~1%, but that number
will move as the estimator gets sharper, and we don't want the UI
chasing it.

Author: amackillop

examples/mdk-nextjs-demo/package.json

@@ -9,8 +9,8 @@
     "lint": "eslint . --ext ts,tsx,js,jsx --max-warnings=0"
   },
   "dependencies": {
-    "@moneydevkit/core": "0.10.0",
-    "@moneydevkit/nextjs": "0.10.0",
+    "@moneydevkit/core": "0.18.0",
+    "@moneydevkit/nextjs": "0.18.0",
     "@radix-ui/react-slot": "^1.2.2",
     "class-variance-authority": "^0.7.1",
     "clsx": "^2.1.1",