oci-registry: a declared registry carrying a project path is rejected as malformed

Current behaviour

resolveReference validates a declared registry against HOST_PATTERN, which allows a host and an optional port and nothing else. A values file written the way Harbor and most self-hosted registries are used:

global:
  imageRegistry: myreg.example.com/project
image:
  repository: my-service
  tag: 1.0.0

resolves to undefined, and checkImageExistence reports { kind: 'unverifiable', reason: 'malformed-reference' } without issuing a request.

Expected behaviour

The declared registry should split on its first /: the head is the registry host, the tail is a namespace prefix on the repository name. The example above should request https://myreg.example.com/v2/project/my-service/manifests/1.0.0.

Notes

The failure is silent and safe — it renders no diagnostic, only a muted question mark — so this is a coverage gap rather than a wrong answer. It was found reviewing #23 and deliberately left out of that ticket's scope, whose acceptance criteria only cover a bare host.

The same question applies to the workspace override set in #25, which takes hostnames from settings. Whatever shape this lands in should be shared with it rather than implemented twice.

Start at resolveReference and checkImageExistence, then inspect the workspace override described in #25 to identify the shared registry parsing path. Add coverage for a registry with a project path and verify that the example resolves to https://myreg.example.com/v2/project/my-service/manifests/1.0.0 without reporting malformed-reference.