fix(drift-sync): bound the sync commit subject so the bot's own PR can merge

[jpr5]

The drift-sync bot built its commit subject by interpolating every changed family. On the first run that recorded ten deprecations, that produced a 525-character header, and commitlint rejects anything over 100 — so the bot opened PR #366 that can never merge, putting a human back in the loop for pure bookkeeping.

This was always latent. It stayed hidden because ten deprecations used to mean "page a human" rather than a mechanical commit, and at one change the unbounded subject is only 94 characters — just under the limit.

Change

The subject is now bounded for any number of changes, degrading by count rather than by characters: it names how many families and which providers, ending in a form whose length grows only with the count's digits. The full per-family detail moves to the commit body, where nothing is lost and body-max-line-length is respected.

The needs-human subject was already a fixed 72-character string and is unchanged.

Verification

Red drives the real construction path with the actual ten deprecations from production run 31225520102. Its output is byte-identical to the bot's real commit 3e70a91 — 525 characters, real commitlint exit 1.

Green, same inputs, measured at 1 / 10 / 50 / 200 changes: 67 / 70 / 70 / 71 characters for one provider, and 67 / 86 / 86 / 87 across all three. Growth is only the count's digits, so the bound is structural rather than a slice. At 200 changes it still reads as a complete sentence; at one change it reads "1 family:", not "1 changes". Fallback forms were forced with synthetic long provider names — they engage at six or more providers and stay within the limit as whole sentences.

Body integrity is proven by building real commits and linting them with the repo's own config: the 200-change message passes with all 200 detail triples present in the stored body.

The checks are non-vacuous, verified by controls that must fail and do: the reconstructed 526-character header fails header-max-length, and a 162-character body line fails body-max-line-length.

Restoring the unbounded interpolation reds 7 of the 10 new tests. The three survivors are honest and explained: at one change the old subject is only 94 characters, which is precisely why this defect stayed invisible until a ten-family run.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@copilotkit/aimock@367

commit: 2aa9257