String array values serialized as Java object reference in ES catchall field

Problem Statement

When a contentlet containing an indexable attribute with a String[] value (e.g., categoryperms) is published, the catchall field in the Elasticsearch/OpenSearch index receives the raw Java object reference ([Ljava.lang.String;@<hashcode>) instead of the actual array elements joined as searchable terms.

Root cause: In ESMappingAPIImpl.java at line 600, the value is appended to the catchall StringBuilder without checking whether it is a String[]. When it is, StringBuilder.append(Object) calls .toString() on the array, which produces the Java reference representation rather than the element values.

Observed in: catchall field after publishing a Content (Generic) contentlet from the empty starter:

... notassigned [Ljava.lang.String;@7d0c268b true ...

Expected: The actual permission category values (the array elements) should appear in catchall as space-separated terms.

This does not appear to have been reported by customers, but the bug is reproducible locally and is provably broken in the current codebase.

Steps to Reproduce

1. Start a dotCMS instance with the empty starter.
2. Open the Content portlet and find a Content (Generic) contentlet.
3. Publish the contentlet.
4. Open the OpenSearch Dashboard and query the catchall field for that contentlet's identifier.
5. Observe that the catchall value contains a token matching [Ljava.lang.String;@<hashcode> — this is the categoryperms field value serialized as a Java object reference.

Expected result: The categoryperms values appear as readable string tokens in catchall.
Actual result: The value appears as [Ljava.lang.String;@<hashcode>.

Acceptance Criteria

• Publishing a contentlet with an indexable String[] attribute (e.g., categoryperms) results in the catchall ES field containing the actual array element values as space-separated tokens — not a Java object reference.
• The original bug scenario (publish Content (Generic) → inspect catchall in OpenSearch Dashboard → see [Ljava.lang.String;@...) no longer reproduces.
• Relationship field values continue to be excluded from the catchall field (existing behavior per Javadoc in ESMappingAPIImpl is preserved — no regression).
• All existing unit and integration tests for ESMappingAPIImpl pass without modification.

dotCMS Version

Reproducible on latest main branch (confirmed 2026-06-18).

Severity

Medium - Some functionality impacted

Links

• Related issue: https://github.com/dotCMS/core/issues/35476 (discovered while working on this)
• Root cause: ESMappingAPIImpl.java#L600

Start in dotCMS/src/main/java/com/dotcms/content/elasticsearch/business/ESMappingAPIImpl.java at line 600, where values are appended to the catchall StringBuilder. Run the existing unit and integration tests for ESMappingAPIImpl, then reproduce the Content (Generic) publishing scenario and inspect catchall in OpenSearch Dashboard. Done means String[] elements appear as space-separated searchable terms, Java references do not, and relationship values remain excluded.