docs(fusion_maintenance): add Westin install-base sizing to Step 0 results

Sized the real serial-tracked install base on sale.order.line: ~138 units / ~136 customers across all funders (walkers 68, wheelchairs 45, power bases 7, scooters 4, +14 with no ADP device_type). Serial# is captured ~only on equipment, so it doubles as a trackable-unit marker. ADP-only gating misses ~28 units (direct_private/adp_odsp/march_of_dimes) -> bridge should key on serial, funder-agnostic. Flags two data gaps (no-device_type units; non-ADP units lacking delivery_date) and reframes the MVP open question as volume (walkers/chairs) vs margin (powered units).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/plans/fusion_maintenance_brainstorm.md

@@ -124,10 +124,9 @@ installed**. Top entries are seating COMPONENTS (Seat Cushion 564, Back Support
 The maintainable **equipment classes** ≈ wheelchairs (manual + power tilt), power bases, power
 scooters, wheeled walkers / walking frames, paediatric standing frames, specialty strollers (~6-8
 clean categories). → `device_type` can't be a 1:1 policy key (119 values, mostly parts); needs a
-grouping/whitelist. **Real install base must be sized on `sale.order.line`** (`x_fc_adp_device_type`
-[computed from product's `x_fc_adp_device_code_id.device_type`], `x_fc_serial_number`,
-`x_fc_adp_approved`; delivery dates `x_fc_adp_delivery_date` / `x_fc_service_start_date`) — **NOT yet
-run; this is the next grounding step.**
+grouping/whitelist. **Real install base sized on `sale.order.line`** (`x_fc_adp_device_type` [stored compute from
+product's `x_fc_adp_device_code_id.device_type`], `x_fc_serial_number`, `x_fc_adp_approved`; delivery
+dates `x_fc_adp_delivery_date` / `x_fc_service_start_date`) — **see the Install-base sizing block below.**
 
 **3) + 4) Enterprise appointment source** — `/mnt/enterprise-addons/appointment`. The no-login token
 slot-picker is **mostly NATIVE — don't hand-roll it**: public booking (`auth="public"`), invite
@@ -146,10 +145,35 @@ email, and hook `calendar.event` create → spawn the service task + advance the
 beds — those belong to the fusion_repairs / EN-Tech (mobility) domain. Westin's recurring-revenue
 play is **wheelchairs / power bases / scooters / walkers / seating**. Open questions updated below.
 
+**Install-base sizing (ran 2026-06-02 — the REAL units, complementing #2's catalog counts).** Big tell:
+serial numbers are captured **~only on actual equipment** (every part/option/mod device_type shows 0
+serials), so `x_fc_serial_number` is already a de-facto "trackable unit" marker — convenient, because the
+bridge's idempotency key is the serial.
+
+- **Addressable base ≈ 138 serial-tracked units across ~136 customers** (all funders). By equipment
+  family (serial-tracked / of which delivered): **Walkers & walking frames 68 (55)**, **Wheelchairs 45
+  (40)**, **Power bases 7 (6)**, **Scooters 4 (3)**, plus **14 units with no ADP device_type** (likely
+  private-pay) and 1 misc.
+- **Funder split** (serial-tracked): adp 109, direct_private 13, adp_odsp 10, march_of_dimes 7;
+  wsib / insurance / standalone-odsp / rental / regular = **0 serials**. → an ADP-only gate
+  (`x_fc_adp_approved`) captures ~110 and **misses ~28** real units. The bridge should likely key on
+  **serial (funder-agnostic)**, not approval.
+- **Two data gaps the design must absorb:** (a) the 14 serial units with no ADP device_type can't be
+  classified by a device_type→policy map → need a product-level or manual category override; (b) non-ADP
+  units have no `x_fc_adp_delivery_date` → the contract anchor (`delivery_date + interval`) needs a
+  fallback (invoice/order date).
+- Deliveries span **2022-10 → 2026-05** (active program) — history to anchor intervals + a live pipeline.
+- Top serial-tracked device_types: Adult Wheeled Walker Type 3 (47), Adult Manual Dynamic Tilt Type 5
+  Wheelchair (23), Adult Lightweight Performance Type 3 (11), Adult Lightweight Standard Type 1 (10),
+  Adult Wheeled Walker Type 2 (9), Adult Power Base Type 3 (5), Power Scooter (3). (1 line ≈ 1 unit;
+  equipment device_types are 1 base line each.)
+
 ## Open questions to resolve with the user (in the connected session)
-- **MVP cut**: reminders+booking for which device categories first? (Step 0 update: stair/porch lifts
-  do NOT exist in Westin's ADP data. Candidates are the powered units most likely to need recurring
-  service — power wheelchairs, power bases, power scooters — then manual wheelchairs / walkers.)
+- **MVP cut**: which categories first? Sizing surfaces a real tension: **by volume** it's walkers (68) +
+  wheelchairs (45) ≈ 82% of the base, but rollators/walkers are mechanically low-service; **by
+  service-revenue-per-unit** the targets are the powered units (power bases 7 + scooters 4 + power
+  wheelchairs) — high maintenance value but only ~11–15 units today. Volume vs. margin — or phase it
+  (powered units first to prove the booking loop, then walkers/manual chairs for reach)?
 - **Revenue mechanic**: auto-draft a priced SO/invoice per booking, vs. pre-paid annual plan, vs.
   pay-at-door via Poynt — which is the default?
 - **Technician assignment**: auto-assign by skill+zone at booking time, or leave dispatch manual