Both found while investigating the Winchester Walking Weekend performance problem.
\nWalks shown as fully booked when capacity is unknown:\nWhen maxCapacity resolves to 0 (loadBookingConfig returns null on the server,\nor the bookingConfig() signal has not loaded yet on the client) the check\ntotalBooked >= maxCapacity was always true, rendering every walk as "Fully\nbooked - all 0 places taken". Guard both the server eligibility endpoint and\nthe client refreshCapacity fallback with maxCapacity > 0 && ... so a 0/unknown\ncapacity is treated as no limit. Genuinely-full walks are unaffected.
\nBatch-send progress map leaked:\nstartBatchTransactionalSend stored a BatchSendProgress in a module-level jobs\nMap for every composer batch send and never removed it, so each send's\nper-recipient progress stayed in memory for the life of the process and pushed\nheapUsed toward the V8 heap limit (~259 MB on a 512 MB machine), causing\nmajor-GC slowness. pruneCompletedJobs() now drops terminal jobs older than 30\nminutes and caps the map at 100 (oldest terminal first); running jobs are never\nevicted and the window leaves time for the client to poll final status.
\nScheduled-run RSS logging:\nexecuteTask records process RSS before and after each scheduled run into\nscheduledTaskRuns.message (via the shared humanFileSize helper), to attribute\nany remaining per-job memory growth.
\n"}