622 integration tests are in no MainSuite and never run in CI

Description

622 integration @Test methods across 99 test classes are not referenced by any MainSuite, so they never run in CI.

Integration tests only execute when their class is listed in one of dotcms-integration/src/test/java/com/dotcms/MainSuite{1a,1b,2a,2b,3a}.java. Registration is manual and nothing verifies it. A developer can write a test class, run it locally with -Dit.test=, watch it pass, open a PR — and CI will run none of it. Nothing about the build output distinguishes that from a test that ran and passed.

This was found while fixing #36827: six new integration classes had been written, run repeatedly, and reported green, and every one of them was unregistered. Checking whether the problem was wider produced the numbers below.

⚠️ Some of these are probably excluded on purpose — check before adding

Do not bulk-add these to suites. A class may be absent from every suite for perfectly good reasons, and adding it blindly could break the build or resurrect work that was deliberately parked. Before touching any entry, establish which of these it is:

• Deliberately excluded — quarantined as flaky, too slow for the suite budget, or superseded by another test.
• Work in progress — belongs to a feature still in flight, where the test is expected to fail or the feature is not finished.
• Environment-dependent — needs something CI does not provide.
• Genuinely orphaned — simply never registered, which is the case this issue is really about.

Only the last category should be added. For the others the correct outcome is to record why, so the next person auditing this does not have to re-derive the reasoning — an @Ignore with a reason, or a comment in the suite, is enough.

The list below is therefore an inventory to triage, not a work list to burn down.

Steps to reproduce the inventory

cat dotcms-integration/src/test/java/com/dotcms/MainSuite*.java > /tmp/allsuites.txt
find dotcms-integration/src/test/java -name "*Test.java" | sed 's#.*/##; s/\.java$//' | sort -u |
while read t; do
  grep -q "\b$t\b" /tmp/allsuites.txt || echo "$t"
done

Acceptance Criteria

• Every one of the 99 unregistered classes is triaged into one of: deliberately excluded, work in progress, environment-dependent, or genuinely orphaned.
• Genuinely orphaned classes are added to an appropriate suite (respecting the "avoid adding more to MainSuite2a" note in that file's header).
• Classes that stay out have the reason recorded in the code — @Ignore("reason") or a comment — so the exclusion is visible rather than implied by absence.
• A CI guard fails the build when an integration test class containing @Test methods is in no suite and carries no recorded exclusion. Without this, the inventory drifts again — this is the part that stops recurrence.
• The guard is proven to work: adding an unregistered test class makes CI fail.
• The 7 unregistered runonce migration tests are triaged as part of this (listed below) — migration tests are cheap and there is rarely a reason to exclude them.

Additional Context

Unregistered runonce migration tests (small, self-contained, likely genuine orphans):

• Task05300UpdateIndexNameLengthTest
• Task211020CreateHostIntegrityCheckerResultTablesTest
• Task221018CreateVariantFieldInMultiTreeTest
• Task230119MigrateContentToProperPersonaTagAndRemoveDupTagsTest
• Task241014AddTemplateValueOnContentletIndexTest
• Task250910AddAnalyticsDashboardPortletToMenuTest
• Task251029RemoveContentTypesLegacyPortletFromLayoutsTest

Related but separate gap: Task260507CreateS3VanityAliasTable has no test at all — not an unregistered test, a missing one. Worth covering while migration test coverage is being looked at, but it is a different problem from this issue.

Priority rationale. Filed as Medium rather than High: nothing is broken for users today, and no product functionality is impaired. The risk is that regressions in these areas land undetected, and that engineers reasonably believe coverage exists where it does not. Triage may well raise it.

Start with the MainSuite1a, MainSuite1b, MainSuite2a, MainSuite2b, and MainSuite3a files under dotcms-integration/src/test/java/com/dotcms, then run the inventory commands in the issue. Done means all 99 classes are triaged, genuine orphans are registered, exclusions have recorded reasons, and a CI guard is proven to fail for an unregistered test class.