Migrating to v0.35.0

One breaking change: the runs-store schema advances from version 13 to 14 so learned profiles carry a sustained CPU figure alongside the peak. The migration is automatic, additive, and applies the moment a v0.35.0 binary opens the store. No adopter code changes. The only action is operational: upgrade every sparkwing binary that shares a runs store in one sitting, because a pre-v0.35.0 binary refuses to open a migrated database.

Runs-store schema advances to version 14

What changes: two additive columns on pipeline_profiles -- sustained_cores and prev_sustained_cores -- both backfilled from their peak counterparts, plus a version bump on the embedded per-profile sample window with the same backfill. Nothing is dropped or rewritten.

What you do: nothing. The first v0.35.0 binary to open the store runs the migration on open in milliseconds, and concurrent opens coordinate at the database level. The step is safe to replay: a process killed mid-migration re-applies it harmlessly on the next open.

Why: admission now charges CPU from a run's sustained demand rather than its burst peak (see the v0.35.0 CHANGELOG entry). The backfill carries every stored profile forward at its current price, so nothing reprices at upgrade -- charges converge on the sustained figure over the next twenty runs per pipeline as fresh measurements fold in.

Rollback: as with every schema advance, a binary older than this release refuses to open a migrated database, naming both versions and the remedy. To roll back the binary, also restore the store from before the upgrade ($SPARKWING_HOME/state.db, default ~/.sparkwing/state.db), or delete it and let it be recreated at the cost of learned profiles and run history.