Vendor ptc-cli 1.0.4

[pavel-te]

1.0.3 printed a GitLab recipe whose first run opened no merge request. It checked git diff --quiet before staging, and git diff looks only at tracked files — on a first run the translations are new files, so the check reported "nothing changed", the push was skipped, and the job went green having produced nothing. Reproduced:

first run, translations are NEW files:
  git diff --quiet          -> exit 0   ("nothing changed")
  git add -A
  git diff --cached --quiet -> exit 1   (the index knows better)

That recipe is printed from inside this action whenever it runs ptc init, so the upstream fix only reaches users through this vendoring.

Also arriving with 1.0.4, since 1.0.3: the rate limit is waited out rather than failing the file, plus test suites for rate limiting, git context and the config examples.

Pins

cli-ref and cli-sha256 in the component template, and PINNED_CLI_VERSION in the self-test. The checksum was verified against what GitHub actually serves at that commit — curl of the pinned ref is byte-identical to the vendored file.

README

It carried the old shape of the GitLab recipe, which nothing printed — neither the action nor a fresh CLI install. It now matches what ptc init emits. Its jq remark is true again: the vendored copy no longer names jq on the apk line.

Fixture

The drift guard was skipping itself: it looked for ptc-cli 1.0.3 while the mock's docstring says ptc-cli.sh 1.0.3, so the version came out empty and the comparison passed. It now refuses to run when it cannot read the version — confirmed by pointing it at a mock claiming 1.0.1.

Not fixed here

The GitLab component template still has the same first-run defect and still commits the whole workspace with git add -A. Tracked separately.

Verification

19 unit cases, 5 act jobs, shellcheck clean.