fix(gcp-secret-get): handle multiline field values (jwt_key)

[gambe94]

Summary

• The export step previously wrote every field as NAME=value appended to $GITHUB_ENV. That format is only valid for single-line values — jwt_key is a multi-line PEM, so writing it that way corrupted $GITHUB_ENV (subsequent lines got parsed as bogus separate declarations).
• Every field now uses $GITHUB_ENV's documented multiline heredoc form (NAME<<DELIM / value / DELIM) with a random per-field delimiter, uniformly for all fields (simpler than branching on single- vs multi-line).
• Masking also moves to per-line (::add-mask:: on each non-empty line of a value), since log masking matches per line — masking a multi-line blob as one token wouldn't reliably redact its individual lines elsewhere in the log.
• Verified locally (see PR description on feat(sf-org-login): add credential-source gcp, via new gcp-secret-get action #33 pattern) that this produces exactly the documented $GITHUB_ENV multiline format before pushing.

Second bug from the same live run that caught #34 (export_to_environment) — that fix got past the "secret is empty" guard, then the JWT login step rejected the decoded key with "not a PEM private key". This is the actual root cause.

Test plan

• actionlint clean
• Local simulation of the export script against a fake multi-line SECRET_JSON, confirmed exact NAME<<DELIM/value/DELIM output
• npm run all — unaffected, all green via pre-push hook
• This PR's CI
• Third re-run of setup-external-app.yml against devhub once this lands and @v2 moves

🤖 Generated with Claude Code