Add multi-tenant cloud mode: self-serve purchase, credit metering, core-decoupling

Introduces RECAP_MODE=multi alongside single-mode self-host:
- Tenant auth + accounts (magic-link via System SMTP), per-tenant credit pool,
  anonymous trial minting with per-IP/-64 caps
- Self-serve Pro/Max purchase: inline Lightning (BTCPay) + card (Zaprite),
  prepaid 30-day periods, expiry-reminder emails
- Core-decoupling: relay owns cloud tier/expiry keyed by Recaps user-id
- SQLite (better-sqlite3) schema for multi-mode; filesystem unchanged for single
- StartOS actions/versions through 0.2.155

startos/versions/v0.2.134.ts

@@ -0,0 +1,13 @@
+import { VersionInfo } from '@start9labs/start-sdk'
+
+export const v_0_2_134 = VersionInfo.of({
+  version: '0.2.134:0',
+  releaseNotes: {
+    en_US:
+      "Trial-cap IPv6 bypass fix. Discovered while investigating an operator report that a single residential network kept minting fresh trial cookies despite a strict cap. Root cause: most modern dual-stack home networks get both an IPv4 and an IPv6 prefix from their ISP, and browsers/OS routinely rotate the lower 64 bits of their IPv6 source address (RFC 4941 privacy extensions). The cap was counting trials per FULL address, so every IPv6 rotation looked like a new IP to the server and granted a fresh trial-cookie quota — meaning one laptop on one home network could mint a new cookie every hour or so. IPv4 addresses didn't have this problem (your public IPv4 is stable for the life of your ISP lease). Fix: cap counting now keys on the /64 prefix for IPv6 (the smallest network unit an ISP delegates to a subscriber, so it's the correct 'this household / this network' boundary) and the whole address for IPv4 (unchanged). The /64 prefix is the half of the IPv6 address that DOESN'T rotate, so a single device cycling through 1000 different IPv6 addresses still counts as 1 trial cookie under the cap. The DB still stores the full IP for forensics; only the count query uses the prefix. Also added a [anon-trial] minted cookie for ip=X cap_key=Y log line at every mint so operators can grep their relay logs to verify the IP detector is working (a flood of mints with ip=null means the StartOS tunnel isn't passing X-Forwarded-For). Side-effect: operators who had pre-fix mints in their DB will see their per-IPv6 row counts collapse to per-/64 totals on the next request, which may push some networks immediately over a tight cap.",
+  },
+  migrations: {
+    up: async ({ effects }) => {},
+    down: async ({ effects }) => {},
+  },
+})