Tolerate an armored/whitespaced SIGNING_KEY (workaround for the valtimo-platform org secret)

[Klaas-Ritense]

Read this before merging. My original diagnosis in this PR was wrong. slack-plugin is not special — the real problem is the org-level SIGNING_KEY secret in valtimo-platform, and this change only makes this one repo tolerant of it. See the evidence below and decide whether you want the org secret fixed instead.

What actually happens

gradle/publishing.gradle calls System.getenv("SIGNING_KEY").decodeBase64() unconditionally. That throws while evaluating the script when the secret is not plain base64:

* What went wrong:
A problem occurred evaluating script.
> bad character in base64 value

Evidence that this is an org-secret problem, not a slack-plugin problem

slack-plugin's workflow and gradle/publishing.gradle are byte-identical to repos that publish fine (diffed against archief-plugin: only the scm URLs differ), and it has no repo-level secrets at all.

Across all 14 valtimo-platform plugin repos:

repo-level SIGNING_KEY	gradle decode	backend publish
override (11 repos)	strict	success
org secret — publictask	tolerant (already fixed)	success
org secret — slack	strict	failure
org secret — value-mapper	strict	success (ran 08:53)

value-mapper looked like a counter-example, so I re-ran it unchanged. It now fails with the identical error. Its earlier success was at 2026-08-17T08:53Z; slack's first failure was 11:21Z the same day.

That pins it down: the org SIGNING_KEY was changed to a non-base64 value (most likely the ASCII-armored key pasted directly) between those two times. Every repo still publishing is protected only by a repo-level override or by the tolerant decode publictask already has.

Two ways forward

1. Fix the org secret (recommended, one change). Re-store valtimo-platform → SIGNING_KEY as plain base64, e.g. base64 -w0 private-key.asc. That fixes slack, value-mapper and every future repo, and lets the 11 repo-level overrides be deleted so the org secret is genuinely the single source. This PR then becomes unnecessary.
2. Merge this as defence-in-depth, and roll the same change out to the other plugin repos so the pipeline works with the key in either form.

Verification of the code change itself

Reproduced locally against this repo by evaluating the build script with each form of the secret:

SIGNING_KEY form	before	after
ASCII-armored (-----BEGIN …)	bad character in base64 value	evaluates cleanly
line-wrapped base64 (36 lines)	evaluates cleanly	evaluates cleanly

Note on publishing either way

publish-backend.yaml triggers on backend/** only, so this change won't re-trigger it — the publish needs a manual re-run to get slack 6.0.1 out. And every plugin repo publishes with publishingType = USER_MANAGED, so the artifact then waits for a manual release at https://central.sonatype.com/publishing/deployments.