Note where the old enhanced query drops references (#760)

projects/pathway-browser/src/app/model/graph/event/event.model.ts

@@ -15,6 +15,12 @@ import { GO_BiologicalProcess } from '../go-term/go-biological-process.model';
  * As /data/query/enhanced sends it, which leaves out what an event has none of:
  * of 15 sampled pathways one had authors, reviewers or a review status, and
  * three of 15 reactions (#344).
+ *
+ * In that answer (not /enhanced/v2) a list such as `literatureReference` can
+ * hold bare dbIds where the object was written earlier in the answer, often in
+ * the parent pathway (`eventOf`); the types here do not say so. Dropping them
+ * loses references, as production's browser does (#760). Take an event's lists
+ * from /enhanced/v2, which writes every object in full.
  */
 export interface Event extends DatabaseObject, InDepth, HasFigure {
   stId: string;

tools/content-node/data-query-endpoints.ts

@@ -391,6 +391,14 @@ export const dataQueryEndpoints: Endpoint[] = [
      * serialiser in the request's view. The entity popup, the website's
      * content pages and the IDG panel read it.
      *
+     * Kept byte for byte as Java answers it, so it keeps a trap: an object is
+     * written in full only once, later as its bare dbId, and since graph-core
+     * bb5e0ca0 (Aug 2025) an event's parent pathways (`eventOf`) come before its
+     * own lists. A reference its parent also cites is therefore a bare number
+     * in the event's `literatureReference`, and a reader that keeps only
+     * objects loses it, which is #760 on production. Read an event's lists
+     * from /query/enhanced/v2 (full objects), as the details pages do.
+     *
      * Its relationships go both ways unless QueryObjectController's
      * needsIncomingRelationship says not (needsIncoming). The id is read as
      * getIdentifier reads it (inDepthId).