fix(pipeline): match catalog pins on project path, not literal host

The pipeline standard failed its two most current consumers for spelling the host correctly.

Its three catalog patterns were anchored on a literal gitlab.com/. GitLab recommends writing the host as $CI_SERVER_FQDN so an include resolves against whichever instance runs it, which is what a self-managed consumer needs. kaniko and manifold use the recommended form and are the only two projects in the group pinned to the current catalog tag. Both reported FAIL. The patterns now match the project path with no host, so either spelling conforms and neither is the thing being asserted.

What this no longer adds

This branch originally added a check_component_resolves primitive, asserting that a pin resolves rather than merely looking like semver. I cut it.

GitLab fails an unresolvable include at resolution time, before any job starts, so the platform already covers every executed pin. Running our own version would add a network call per pin across 25 consumer pipelines to buy earlier notice on a case the platform reports anyway. _lib.sh sets the bar for a new primitive at coverage rather than convenience, and says a primitive that never grows past one call site is "vocabulary without leverage". This one had a single call site.

The standard now carries an unasserted: line recording the gap instead, which is the honest form. The closed primitive set stays at ten.

Verification

just validate all gates green. just guard reports 10 primitives, 0 violations. The standard reports 5 passed and 0 failed against kaniko's real .gitlab-ci.yml, which previously failed. vale reports 0 errors on the changed SKILL.md.