[Tyagiquamar]

Summary

Improves the error messages returned when a container token request uses freeze mode without a custom build repository, replacing the cryptic freeze mode [1] / [2] / [3] placeholders with messages that explain why buildRepository is required.

Root Cause & Problem

When a request enables freeze mode without specifying a buildRepository, ContainerController.handleRequest rejects it with generic messages containing opaque numeric codes (... using freeze mode [1], [2], [3]). These give no indication of what the caller should change, which is especially confusing because freeze mode is allowed without an explicit repository in some cases (for example Conda or pip packages frozen to the default public Seqera Containers repository). See issue #723.

Technical Solution

In ContainerController, the three freeze-validation guards now throw descriptive messages:

• freezing a Dockerfile requires a custom build repository, since only Conda and pip packages can be frozen to the default Seqera Containers repository;
• freezing an existing container image requires a custom build repository;
• freezing packages requires either a custom build repository or a configured default public repository.

Test Plan

• Added FreezeValidationTest, a lightweight Spock unit test that constructs ContainerController directly with mocked collaborators (it does not boot the Micronaut application context), covering all three freeze-validation branches.
• Validation run on JDK 25:
  • Post-fix: gradle :test --tests io.seqera.wave.controller.FreezeValidationTest -x installTypeSpec -x generateOpenApi -x generateSwaggerUI → BUILD SUCCESSFUL, 3 tests passed.
  • Pre-fix (with the code change stashed): the same command → all 3 tests failed with message mismatches, confirming the regression test fails before the fix and passes after it.
• Updated the existing ContainerControllerTest assertions to match the new messages so the full test suite stays green.

Fixes #723