docs(issues): live re-test results for ISSUE-102 and ISSUE-90 on the rebuilt platform

PYEGERIA_ISSUES.md

@@ -286,7 +286,7 @@ downstream investigation.
 
 ### ISSUE-102: `MemberDataField.minCardinality` silently persists as `maxCardinality`'s value regardless of what's actually sent — server-side, confirmed via a raw request bypassing every pyegeria/Dr.Egeria layer
 
-**Layer:** Egeria Server (repository/relationship-property persistence) · **Status:** open · **Found:** 2026-09-17, live-verifying a Dr.Egeria fix for `Position`/`Minimum Cardinality`/`Maximum Cardinality` on the field↔structure `MemberDataField` relationship (`qs-view-server`/`qs-metadata-store`, versionName `6.2-SNAPSHOT`).
+**Layer:** Egeria Server (repository/relationship-property persistence) · **Status:** NO LONGER REPRODUCES on the 2026-10-05 rebuilt platform (see the re-test below) · **Found:** 2026-09-17, live-verifying a Dr.Egeria fix for `Position`/`Minimum Cardinality`/`Maximum Cardinality` on the field↔structure `MemberDataField` relationship (`qs-view-server`/`qs-metadata-store`, versionName `6.2-SNAPSHOT`).
 
 Confirmed with the type system's own definition
 (`ValidMetadataManager._async_get_all_relationship_defs()`, filtered to
@@ -295,6 +295,26 @@ Confirmed with the type system's own definition
 cardinality, no documented interdependency between `minCardinality` and
 `maxCardinality`.
 
+**Re-tested 2026-10-05 on the rebuilt platform** (Egeria image built 14:19Z from main `449ad06894`,
+`egeria-main` restarted 14:39Z). One throwaway `DataStructure` and four `DataField`s were linked with
+`MemberDataField` and each relationship was read back via the endpoints lookup
+(`get_metadata_element_relationships`). **All four stored correctly** (`position` always right):
+
+| sent (min, max) | stored (min, max) |
+|---|---|
+| 1, 5 | 1, 5 |
+| 2, 7 | 2, 7 |
+| 0, 5 | 0, 5 |
+| 3, *omitted* | 3, 0 |
+
+Everything was deleted child-first and verified gone. **The bug no longer reproduces.** The cause of the fix is not
+known: a source comparison of the bean (`MemberDataFieldProperties`/`PartOfRelationshipProperties`), the read
+converter and the relationship builder between 2026-09-15 and `449ad06894` found no change, so either the fix is
+in code that was not inspected or the build that showed the bug on 2026-09-17 was older than that baseline. Worth
+asking the Egeria team which change fixed it before closing this for good. Side observation, separate from this
+bug: an omitted `maxCardinality` is stored as `0` (the bean default), below a supplied minimum; the bean's own
+documentation says `-1` means unlimited.
+
 **Repro (isolated with a raw SDK call — no Dr.Egeria markdown, no pyegeria
 body-construction logic in the path beyond `EgeriaTech.data_designer`):**
 ```python
@@ -424,6 +444,29 @@ security context changes; (2) quickstart content: give `generalnpa` read access
 elements its engine actions anchor to, or anchor those actions to elements the engine-host identity can
 read. Full draft: trellis session scratch `egeria-issue-engine-host-403-loop.md`.
 
+**Re-tested 2026-10-05 on the rebuilt platform** (image built 14:19Z from Egeria main `449ad06894`;
+`egeria-main` restarted 14:39Z; checked 32 minutes later, read-only):
+
+- **Not reproduced.** Zero `ENGINE-HOST-SERVICES-2002`, zero `startMissedEngineActions` and zero
+  `OMAG-SERVER-SECURITY-403-007` in the platform log since the restart; the engine host is refreshing its governance
+  engines normally. CPU is calm: the platform container about 50% of one core and Postgres about 30%, against 200-330%
+  and 500-750% in the original report.
+- **But the trigger was absent, so this proves little.** Only two engine actions are active: a `REQUESTED` PostgreSQL
+  survey and the `IN_PROGRESS` `EgeriaWatchdog`. `startMissedEngineActions` only processes `APPROVED` actions (read in
+  `GovernanceEngineHandler`), so it had nothing to retry. As this entry already said, the loop depends on start-up
+  history; a clean run cannot distinguish "fixed" from "not triggered".
+- **The code is unchanged where it matters.** Between 2026-09-15 and `449ad06894` the only change to
+  `startMissedEngineActions` is `logException` becoming `logMessage` in the per-action `catch`. The outer `catch` that
+  aborts the whole pass on a failed page fetch is untouched, so an `APPROVED` action with an unreadable anchor would
+  still loop.
+- **Unreadable anchors do exist on this platform.** 381 `OPEN-METADATA-SECURITY-0011` "not authorized to issue operation
+  Read" messages in 32 minutes, all for user `erinoverview`, across 11 elements anchored to a `DigitalProduct` (6) or a
+  `DigitalProductFamily` (5), arriving in bursts of 20 that match page-sized searches, not a steady background loop.
+  None were for `generalnpa`, and the element from the original report (`a0baa4da-...`) is not among them. So the
+  quickstart content does carry elements an ordinary user cannot read, which is the precondition this entry
+  hypothesised; whether any engine action anchors to one is not shown.
+- **Status:** still open, latent. Not reproduced here; not shown fixed.
+
 ---
 
 ### ISSUE-38 (PY-18): `count_relationships_between_elements("Exception")` (276) disagrees with `ClassificationExplorer.get_relationships("Exception")` (55)