Port OIDC/KMS trust architecture to release-julia-1.13

[Keno]

Bring the post-#544 CI architecture to the release-1.13 branch so that release-branch PRs run under the shared julia-pr pipeline and release nightlies run under julia-ci -> julia-publish, instead of the old per-release pipeline slugs (julia-release-1-dot-13, julia-master-scheduled, julia-buildkite). Per-release differences are now expressed as branch content selected by julia's in-repo .buildkite-external-version pointer, not by runtime pipeline.slug checks -- so no separate Buildkite pipelines are needed (the shared julia-ci/julia-publish already branch-limit to master release-*).

What changed:

• Retire the cryptic secret-management + signed/unsigned pipeline split (cryptic_repo_keys/, secrets/, .signature, launch_signed_jobs.yml, launch_unsigned_.yml, launch_upload_jobs.yml, platforms/upload_*.yml).
• Adopt main's OIDC + AWS KMS trust infrastructure, the single-upload render_launch_pipeline.py launcher, and the trusted julia-publish / julia-publish-test pipelines. The trailing wait + trigger: julia-publish is gated on pipeline.slug == "julia-ci".

Preserved as release-1.13-specific:

• The build/test matrix: every pipelines/**/platforms/*.arches file is kept verbatim from release-julia-1.13 (rootfs v6.00 / docker v7.10, mmtk on the package_linux image, Windows CFLAGS), plus launch_powerpc.jl.
• The job set: render_launch_pipeline.py is trimmed to omit the JuliaSyntax and JuliaC launch groups (new on main; not part of release-1.13 CI). The juliasyntax.* / juliac/ YAMLs remain in-tree so either can be re-enabled by re-adding its blocks.append(...).

NOT yet validated on Buildkite -- needs a CI run under the shared pipelines.

[DilumAluthge]

Can this be done as a cherry-pick of d52faac instead?

Otherwise, I worry that future cherry-picks from master to release-* won't work.

[Keno]

We can invert in and re-create a 1.13-specific commit on top of master rather than porting master to 1.13.