mirror: --modules-path-suffix is ignored on both pull and push

Summary

The --modules-path-suffix flag (default /modules) is documented as controlling where modules are located in the source registry, but changing it has no effect on either d8 mirror pull or d8 mirror push. The module repository segment is effectively hardcoded to modules.

Details

Pull. The only code that reads params.ModulesPathSuffix is Puller.validateModulesAccess in internal/mirror/cmd/pull/pull.go, and that method is never invoked in production — the only caller is internal/mirror/cmd/pull/pull_test.go. The modules service builds every reference from a hardcoded segment:

• internal/mirror/modules/modules.go — filepath.Join(svc.rootURL, "modules", moduleName) and svc.rootURL + "/modules/" + ...
• pkg/registry/service/service.go — moduleSegment = "modules", NewModulesService(base.WithSegment(moduleSegment), ...)

Push. ModulesPathSuffix is stored into params (internal/mirror/cmd/push/push.go) but never read. The push segment is derived from the layout directory / the fixed internal.ModulesSegment (internal/mirror/push.go, pushSingleLayout).

Impact

A user who points --modules-path-suffix at a non-default value is silently ignored; mirroring always targets the default modules segment. The default value happens to work only because it equals the hardcoded segment.

Expected

Either make the flag actually change the module path, or remove it and document that the module segment is fixed.

As of main (62132d6a).

Start in internal/mirror/modules/modules.go and pkg/registry/service/service.go to trace the hardcoded modules segment, then compare pull.go with pull_test.go. Review internal/mirror/cmd/push/push.go, internal/mirror/push.go, and pushSingleLayout to trace the push path. Done means the flag consistently changes both pull and push module paths, or is removed with its behavior documented.