ci: fix dependency clone auth header for GitHub's new long token format

[Florian Ruppel (fruppel)]

The intermittent Failed sending HTTP request errors since 2026-07-18 (#181, #182 context) are not a network/transport problem.

GitHub is rolling out a new ~390-char token format (ghs_<id>_<JWT>, "ver":3 in the payload). The dependency clone loop builds its auth header with:

... "AUTHORIZATION: basic $(echo -n "x-access-token:${dep_token}" | base64)"

GNU base64 wraps output at 76 chars. Old tokens (x-access-token: + ~40 chars = 55 chars) fit on one line; new-format tokens produce a multi-line header value, and libcurl rejects headers with embedded newlines — on the runner's curl version this surfaces as Failed sending HTTP request (curl error 55), before a single byte is transferred.

Symptom	Explanation
Started 2026-07-18, ~30–50 % of runs	fraction of jobs receiving a new-format token from octo-sts
Fails within ~60 ms	header rejected client-side before the request is sent
All 3 in-job retries fail	same (long) token for the whole job — this is also why #182's HTTP/1.1 retry can't help
Only the dependency clone step	actions/checkout encodes via JS Buffer (never wraps); downstream/action.yml already uses base64 -w0
'Only SwagCommercial'	it's simply the first dependency in the loop — the job dies before the others are attempted

Reproduction

FAKE_TOKEN="ghs_15368_$(printf 'A%.0s' {1..370})"
HEADER="AUTHORIZATION: basic $(echo -n "x-access-token:$FAKE_TOKEN" | base64 | fold -w76)"
git -c "http.https://github.com/.extraheader=$HEADER" clone https://github.com/shopware/SwagExtensionStore.git
# fatal: unable to access '...': A libcurl function was given a bad argument
# (same failure class; message text varies by curl version)

Fix

base64 -w0, exactly like downstream/action.yml:81 already does.

Related findings (separate follow-ups needed)

1. shopware/Rufus .github/actions/setup-rufus/action.yml has the same unwrapped base64 for the masterchief-sdk header — same fix needed there.
2. Re-runs of Downstream workflows fail with could not read Username: the workflow_dispatch payload carries a token from the original upstream run, which is revoked/expired by re-run time. Re-runs of downstream runs can never work this way.
3. ⚠️ That dispatched token is a plain workflow input and is logged unmasked in the job logs (visible to anyone with read access while valid, up to 1 h). Worth a separate security review of the downstream trigger mechanism.