Gantry: 1 - Registry credential safety

## Scope

Fix boundary-independent credential exposure in the origin registry bearer-token flow.

## Problem

`origin.fetchBearerToken` trusts the `WWW-Authenticate` bearer `realm` verbatim and attaches Basic credentials. A malicious or compromised registry response can direct Gantry to send long-lived registry credentials to an attacker-controlled token endpoint. Config also allows `http://` upstreams.

Evidence:

- `internal/gantry/origin/origin.go:565`
- `internal/gantry/origin/origin.go:581`
- `internal/gantry/config/config.go:703`

## Changes

- Parse `realm` in `origin.fetchBearerToken` and reject any realm whose scheme is not `https` before creating the token request.
- Continue allowing configured registry endpoints with `http://`, but do not attach Basic credentials when the configured registry endpoint is `http://`.
- Store credential-send policy on `registry` at construction time, for example based on `r.base.Scheme == "https"`.
- Do not require the token realm host to equal the registry host by default, since Docker Hub and others use separate HTTPS auth hosts.
- Optional follow-up: add an operator allowlist for HTTPS token realm hosts.

## Tests

- `http://` token realm is rejected.
- Cross-host `https://` token realm is accepted.
- Basic credentials are not sent for an `http://` configured registry endpoint.
- Error strings and logs do not include credentials.

Start with internal/gantry/origin/origin.go at lines 565 and 581, then inspect registry construction and internal/gantry/config/config.go around line 703. Trace fetchBearerToken and the configured endpoint scheme before adding tests for HTTP realm rejection, cross-host HTTPS acceptance, suppressed credentials on HTTP registries, and credential-free errors and logs.

Written by the indexing model from the issue text.