ENH: Investigate randomized triangle face IDs and metadata alignment #1774

Summary

Investigate whether Compute Triangle Face Ids preserves the relationship between randomized boundary IDs and its boundary label/count table.
A boundary is the set of triangles sharing one unordered pair of feature labels.
The table contains one row per boundary.

This remains an unconfirmed source finding. No reproduced output defect is established in the report.
Confirm the intended ID-to-row contract and obtain a bounded nonidentity permutation before choosing a correction.
Use a separate branch from the out-of-core audit for this investigation and any shared correction.

At 2eb6b878f6ff408d1454754d4c0e63edd676d7e0, the randomizer changes per-triangle boundary IDs.
The caller populates label/count rows before randomization and then returns.
No corresponding table permutation appears in this path.
The documentation describes the table and visual relabeling, but does not explicitly define randomized ID lookup.

The original source finding covers resident and bounded out-of-core paths on published PR #1764 head 9a28a90f0f7a5d42fb5f17f36c84597b640fcac9.
Pinned develop contains the resident implementation; the additional out-of-core path from that report is absent.
That branch-specific observation is historical and is not independently confirmed here.

Under the usual ID-as-row-index interpretation, changed IDs can select unchanged metadata for another boundary. This consequence is inferred.
For illustration, swapping IDs 1 and 2 without moving distinct metadata rows breaks that relationship.
This example is not an observed runtime permutation.

The requested bounded investigation is:

1. Resolve the separate shared-map insertion/read race in BUG: Avoid concurrent map insertion in Compute Triangle Face Ids #1772, or use an explicitly controlled single-thread diagnostic.
   A serialized diagnostic does not validate ordinary parallel execution.
2. For each group j from 1 through G, create exactly j valid triangles with label pair (10*j,10*j+1).
   Alternate pair order within each group. Present groups in increasing first-encounter order. Use distinct counts and pairs, without (0,0) input.
3. Run fresh fixtures with Randomize Face IDs off and on through both resident scenarios and the actual HDF5-backed path on the branch containing the reported implementations.
4. With randomization off, independently expect group ID j, label row (10*j,10*j+1), count j, and the reserved zero row.
5. With randomization on, require one in-range ID per group and distinct IDs between groups.
   Use each observed output ID to select its metadata row. Compare that row with the independently known label pair and count.
6. Start with G=4. If its permutation is identity, try G=2..16 until a nonidentity permutation appears.
   This bounds the largest fixture at 136 triangles. Identity-only output cannot test this concern.
7. Record complete group-to-ID mappings, table rows, revisions, algorithm/store selection, valid results, and preserved inputs.

Do not derive expected permutations from the production shuffle, seed, or standard-library distribution.
Platforms can produce different permutations. The relationship assertion must remain valid across them.

The possible outcomes remain open:

• If IDs index rows and lookup fails, apply one consistent mapping to IDs and metadata.
  Preserve grouping, counts, row zero, and bounded out-of-core transfers.
  Existing pipeline metadata associations can change; assess regression coverage and release notes.
• If randomized IDs are display-only, document that contract and provide a usable relationship between outputs.
  Do not leave the mapping ambiguous.
• If output stays aligned, explain why the source observation differs from execution and retain an independent passing relationship test.

Do not change random-number policy, seed sequence, or grouping order solely to repair alignment. Those are separate compatibility decisions.
Acceptance requires a documented contract and a bounded nonidentity runtime case, or an explicit explanation that the concern is not reproduced.
Check all IDs, label/count rows, input preservation, and real stores in both algorithm paths.
If a required path is unavailable, record that coverage as outstanding.
Once the contract is settled, cover randomized read/write failures.
Keep multithreaded safety separate from this numerical relationship. Fixing #1772 does not establish alignment, and alignment does not establish thread safety.
The standalone Randomize Feature Ids defect in #1785 is a separate path.