Fix CleanUpFieldReferencesJobTest failing to instantiate under Weld when run individually

Description

CleanUpFieldReferencesJobTest cannot be instantiated when run on its own (e.g. a single-test run from the IDE, or -Dit.test=CleanUpFieldReferencesJobTest). Weld fails to resolve the test class as a bean and the run dies before any test method executes:

org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334: Unsatisfied dependencies for type CleanUpFieldReferencesJobTest with qualifiers
    at org.jboss.weld.bean.builtin.InstanceImpl.checkBeanResolved(InstanceImpl.java:241)
    at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:113)
    at com.dotcms.DataProviderWeldRunner.createTest(DataProviderWeldRunner.java:38)

Root cause

DataProviderWeldRunner.createTest() builds the test instance through the CDI container:

return CONTAINER.select(getTestClass().getJavaClass()).get();

dotcms-integration/src/test/resources/META-INF/beans.xml declares bean-discovery-mode="annotated", so a class is only registered as a bean when it carries a bean-defining annotation. The test class had none, so select(...) resolves to nothing and throws.

The test was also still declaring @RunWith(DataProviderRunner.class), which does not go through the container at all — so the class had drifted from the pattern the rest of the module uses.

Fix

Bring the class in line with the convention already used by the other 11 Weld-based tests in dotcms-integration (OSIndexAPIImplIntegrationTest, DependencyBundlerTest, SiteSearchDualWriteRouterIT, MigrationPhaseStoreBootstrapIT, …):

@ApplicationScoped
@RunWith(DataProviderWeldRunner.class)
public class CleanUpFieldReferencesJobTest extends IntegrationTestBase {

plus dropping the now-unused DataProviderRunner import.

Test-only change — no production code is touched.

Acceptance Criteria

• CleanUpFieldReferencesJobTest runs green when executed on its own from the IDE (single-class run) with no UnsatisfiedResolutionException
• CleanUpFieldReferencesJobTest runs green when executed on its own via Maven: ./mvnw verify -pl :dotcms-integration -Dcoreit.test.skip=false -Dit.test=CleanUpFieldReferencesJobTest
• All 4 data-provider cases (checkboxFieldVarName / dateTimeFieldVarName, JSON and column-backed variants) still execute and pass
• The test still passes as part of MainSuite2b, where it is registered
• The class carries @ApplicationScoped and @RunWith(DataProviderWeldRunner.class), matching the other Weld tests in the module
• No unused imports remain in the file

Priority

Low

Additional Context

Only the individual-run path was broken; the suite run masked it. Worth keeping in mind for any other test still on @RunWith(DataProviderRunner.class) that also needs container-managed instantiation — the failure only shows up when the class is run in isolation.

Start with CleanUpFieldReferencesJobTest and compare its runner and bean-defining annotations with the other Weld-based tests named in dotcms-integration. Run the individual Maven command from the acceptance criteria, then verify all four data-provider cases and the MainSuite2b run pass without an UnsatisfiedResolutionException or unused imports.