Restore trusted GitHub API transport across scheduled release recovery

[rmcdaniel]

Problem

Scheduled release recovery is failing across Workflow, Server, Waterline, PHP SDK, and Python SDK before release-plan discovery completes. The shared recovery client reports:

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate

Recent examples include Workflow run 31548351445 and PHP SDK run 31548537021. Server, Python SDK, and Waterline recovery schedules show the same failure period. GitHub currently reports its services operational, so repeated cross-repository failures cannot remain classified as a stale deployment or a one-repository package problem.

The protected publication jobs remain skipped, so no unverified package was published, but the recovery safety net is currently unavailable and produces noisy red runs.

Acceptance criteria

• Keep TLS certificate verification enabled. Do not use an unverified SSL context, suppress certificate failures, pin an ephemeral leaf certificate, or add an untrusted certificate to the repository.
• Use a GitHub Actions-supported trust path for GitHub API requests and prove it against the runner environment used by every recovery workflow.
• Apply bounded retry only to genuinely retryable transport failures, with structured evidence that distinguishes transport unavailability from release-plan rejection.
• Preserve fail-closed publication: a transport failure cannot create a tag, package, image, or GitHub Release.
• Make scheduled no-op recovery report an accurate neutral/runner-transport outcome after retries rather than presenting a package deployment failure.
• Add regressions for a transient certificate failure followed by success, persistent trust failure, ordinary HTTP/API failure, and an authorized publication path.
• Update every repository copy or shared authority together so Workflow, Server, Waterline, PHP SDK, Python SDK, Rust SDK, and CLI do not diverge.
• Record clean scheduled recovery runs in representative Composer, Python, container, and source-package repositories after the fix lands.

Delete when

Delete when scheduled recovery can use the trusted GitHub API path consistently across the release repositories, persistent trust failures remain fail-closed and diagnosable, and subsequent scheduled runs no longer fail with the self-signed-certificate error.