Let replicate relay against targets advertising no-thin

Targets built on go-git's receive-pack (including entire-server) unconditionally advertise the no-thin capability because go-git has a "TODO: support thin-pack" in plumbing/transport/serve.go. Replicate previously rejected such targets with "use sync instead", which made the mode unusable against the most common internal target.

Reconsidered the constraint: our upload-pack client (gitproto.fetchPackV1 / fetchPackV2 / fetchToStoreV1) never sets the "thin-pack" capability in the request. By protocol rules the source only emits thin packs when the client explicitly asks for them, so the pack we relay is always self-contained and safe to push to a no-thin receive-pack. The rejection was overcautious.

Changes:

• planner.SupportsReplicateRelay no longer fails on target.NoThin. It returns ok with reason "replicate-target-capable-no-thin" so callers can still observe the distinction in logs and JSON.
• gitproto fetch code gets explicit comments at both the v1 and v2 upload-request build sites documenting that we do not request thin-pack and that SupportsReplicateRelay depends on that invariant. Anyone adding thin-pack support later must update the planner check to gate on target NoThin.
• Integration test flipped: replicate against a no-thin target must now succeed and leave source and target heads matching, rather than fail with "use sync instead".
• Planner test split into "tolerates no-thin" and "rejects unknown capabilities" so the two branches of SupportsReplicateRelay each have direct coverage.
• CHANGELOG and docs/architecture.md updated to explain the new behavior and the thin-pack invariant.