the first-Init port guard excuses every container this service's agent kept (#1201)

* fix(run): the first-Init port guard excuses every container this service's agent kept, not just one named after the service

An agent may run SEVERAL containers for one service and names each after
itself: service-object-storage publishes the service's own grpc port from
`<unique>-gateway` and keeps `<unique>-minio` and `<unique>-network` beside it.
The guard added in #1180 excused only a container named exactly
`ContainerName(<unique>)`, so it excused none of them — and `adoptableContainer`
could therefore never match a keep-running agent that suffixes its container
names, which is the fleet's actual convention.

What that cost: the first flow of a job starts the service fine and leaves its
gateway container up, publishing the service's deterministic port. A later flow
in the same job builds a fresh Runner, so `everStarted` is false and the guard
runs, finds the port bound by Docker's forwarder, fails to attribute it to this
service's own container, and refuses. Deterministically, in every phase, which
is what saas#1265 hit on both of its runs — the first run of that graph on a
release carrying #1180.

A container is now this service's when its logical name label and its Docker
name are the service's name or that name with a suffix. Every other guard is
unchanged: the codefly owner label, this flow's exact recovery scope, the
namespace rule, running, non-ephemeral, and the container must publish the
proposed port on that address's own loopback family. A sibling service is still
not this one, and a squatter is still refused on either family.

Diagnosed by reproduction rather than inference, with the RELEASED 0.1.219 in a
repo unrelated to saas: `codefly run service documents/object-storage
--init-only` twice in one workspace and scope leaves
`…-object-storage-osproof-gateway` publishing 0.0.0.0:47103 and then refuses
`port 47103 (grpc) held by pid … (OrbStack Helper)` — the Docker forwarder, so
the holder is the kept container and neither a leaked process nor a port
derivation. The same second flow passes with this fix. Restoring the old
comparison makes the two new unit cases fail with that same refusal.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(orchestration): require exact parent attribution for sidecars

* docs(orchestration): bound container attribution claims

* fix(conformance): track the selected Core release line

---------

Co-authored-by: Antoine Toussaint <312536060+antoinetoussaint-byte@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: antoinetoussaint-byte