Summary

On a clean utPLSQL v3.2.2 install against Oracle AI Database 23ai, build 23.26.1, a trivial
--%suite owned by a non-owner schema (the schema is not UT3) is not resolved by
UT_SUITE_MANAGER: running ut.run as that schema returns ORA-20204 "suite does not exist".
In the same environment the annotation DDL trigger UT_TRIGGER_ANNOTATION_PARSING does not appear
to register / fire, so the annotation cache is never populated for the non-owner schema's objects.

The same install pattern works on earlier 19c/21c environments in our experience; the symptom appears
specific to the 23.26.1 build (newer than the 23ai range utPLSQL appears to have been tested against).

Environment

Steps to reproduce

1. Install utPLSQL v3.2.2 headless as owner UT3 (install.sql), then run the official
   per-user grants for the non-owner application schema (create_grants.sql / create_synonyms.sql),
   i.e. EXECUTE on the UT3 program units/types and the public synonyms.
2. Connect as the non-owner application schema and create a trivial suite:

   CREATE OR REPLACE PACKAGE demo_suite IS
     --%suite(Demo)
     --%test(trivial passes)
     PROCEDURE trivial;
   END;
   /
   CREATE OR REPLACE PACKAGE BODY demo_suite IS
     PROCEDURE trivial IS BEGIN ut.expect(1).to_equal(1); END;
   END;
   /

3. Still as the non-owner schema:

   BEGIN ut.run('DEMO_SUITE'); END;
   /

Expected

The Demo suite is discovered and the trivial test runs green.

Actual

ORA-20204: suite DEMO_SUITE does not exist
ORA-06512: at "UT3.UT_SUITE_MANAGER", line ...

Inspecting further: UT_TRIGGER_ANNOTATION_PARSING does not register for the non-owner schema, so the
annotation cache is never populated, and UT_SUITE_MANAGER finds no suite. A manual
ut_annotation_manager.rebuild_annotation_cache(...) for the schema does not repair discovery.
UT_RUNNER, UT_SUITE_MANAGER, and UT_ANNOTATION_MANAGER are all AUTHID CURRENT_USER.

What we have already ruled out

• Grants are complete — the full official create_grants.sql object set (65 objects), EXECUTE on all
  UT3 types, SELECT/DML on the annotation-cache tables, plus public synonyms and a manually-populated
  annotation cache: still ORA-20204.
• Owner-side install is clean — a full owner-side reinstall/upgrade connected AS UT3 (v3.2.2,
  380 objects, 0 INVALID) did not change the non-owner result.
• Not FIPS / not MD5 — DBFIPS_140=FALSE; SHA-256 (utPLSQL's default hash) works on this DB. The
  FIPS/ORA-28817/MD5 thread (ut_coverage_html_reporter fails with ORA-28817 in FIPS-enabled databases due to MD5 usage in DBMS_CRYPTO #1316 → PR Allow HTML coverage on FIPS-enabled DB #1356, shipped in v3.2.2) does not match this symptom.
• Not a context-path case — distinct from ORA-20204 raised when running a context path #1317 (PascalCase context names on 19.3) and DDL Trigger not working #1088
  ("DDL Trigger not working", not 23.26-specific). Running tests from UT3 user in other schema corrupts annotation cache #1051 is the opposite direction (running as the owner).

Question / request

Is non-owner-schema suite discovery expected to work on the 23.26.1 build, and is there a known
fix or workaround? If this is an unaddressed regression on the newer 23ai build, we are happy to provide
any further diagnostics (DDL-trigger registration state, annotation-cache contents, UT_SUITE_CACHE
rows for the schema, full version banner) to help reproduce.