history store's state.count is rows-returned, not the total

[arlophoenix]

Body

src/store/history/mutations.ts sets state.count from payload.count on every server.history.list response. Moonraker's _handle_jobs_list ends with return {"count": len(jobs), "jobs": jobs} — count is the length of the page it just returned, not the number of rows in the table. After history/init runs with limit: Globals.JOB_HISTORY_LOAD, the store holds count === 50 and jobs.length === 50 on any printer with 50 or more jobs.

That makes count unusable as an "is everything loaded" signal, which is the obvious thing to reach for. Any guard of the shape if (jobs.length >= count) { /* everything is loaded */ } is permanently true and would silently disable whatever it guards. This was very nearly written into a fix before the semantics were checked.

setDeleteJob also splices state.jobs without touching count, so it drifts further as jobs are deleted.

Nothing reads state.count today, so there is no user-visible bug — this is about the trap it sets. Worth either fixing the semantics, or removing the field, or documenting what it actually holds.

For the record, there is no reliable total available either: job_totals.total_jobs is a lifetime counter that survives deletes and is zeroed by server.history.reset_totals.