v0.9.18 - start endpoint + connection strings survive a recycle

Internal fork release.

Added

• POST /api/migration-jobs/{jobId}/start — start or resume a job without the UI. The body is optional; omit it to reuse the job's stored connection strings, or supply sourceConnectionString/targetConnectionString to rotate a credential. Mirrors the UI start path including the sync-back branch, reuses the existing loopback + X-Migration-App-Password guard, and returns 404 for an unknown job, 409 if a migration is already running or the job is complete, and 400 if the supplied connection strings resolve to different endpoints than the job recorded.

• Connection strings now survive a recycle. They previously lived only in static in-memory dictionaries, so an app-pool recycle, iisreset or redeploy dropped them and a started job could not be resumed without re-entering them by hand. They are now encrypted with ASP.NET Core Data Protection to <state-store>/connections/<jobId>.dat. The key ring lives under the state store rather than the app directory, which a redeploy replaces; on Windows the key ring is itself encrypted with machine-scoped DPAPI. Entries are removed when their job is deleted.

Fixed

• Auto-resume could never fire on a host with more than one job. ActiveMigrationJobId is a plain static that is never rehydrated from disk, and the recovery path was additionally gated on there being exactly one job. It now resumes the single job that is started, not completed and not cancelled.

• The version shown in the page header was hardcoded and had been left at v0.9.15 through two releases. It is now set once in the csproj and read from the assembly, so it cannot drift again.

Verification

Built from the merged commit; the assembly informational version embeds that SHA. An 11-check harness compiled against the real ConnectionStringVault confirmed a fresh instance loads what a prior instance saved, that payloads on disk carry no plaintext credentials, and that corrupted payloads degrade to a miss rather than throwing.