Output Properties tab hides read-only nested properties and shows writable ones #363

Steps to reproduce

1. Open a resource type whose schema has a read-only object property, where that object has read-only children — for example a status object marked readOnly: true containing a read-only phase and a writable note.
2. Open the Output Properties tab.

Observed behavior

The nested table for status lists note and omits phase.

That is the exact inverse of what the tab is for. phase is a read-only value in an object that is itself read-only, and it is visible in neither tab:

• the Properties tab drops the whole status subtree, because the parent is read-only;
• the Output Properties tab keeps the parent but drops phase, because its nested filter still selects writable children.

So a read-only leaf under a read-only parent is unreachable in the UI, while a writable leaf is shown in the read-only tab.

Cause

ResourceTypeDetailPage.tsx contains the Properties tab (roughly lines 398–1575) and the Output Properties tab (roughly lines 1577–2680) as two near-duplicate blocks of about eleven hundred lines each. They are intended to differ only in one predicate:

• properties tab, line ~642: const isReadOnly = typedProp.readOnly === true; return !isReadOnly;
• output tab, line ~1826: const isReadOnly = typedProp.readOnly === true; return isReadOnly;

The top-level filter was inverted correctly when the block was copied. The nested expansion filters were not. Lines ~1925, ~2033, and ~2135 — inside the output tab — still read return typedNestedProp.readOnly !== true;, which is the properties tab's predicate.

Desired behavior

The Output Properties tab should show read-only children of a read-only object, and should not show writable ones.

The underlying problem is the duplication, not the three predicates. Two copies of eleven hundred lines that are meant to differ by one boolean will keep drifting; this is already the second divergence found in that pair. The durable fix is to render both tabs from one parameterised component.

Workaround

Use the Details tab, which shows the raw resource-type payload including the full schema.

Additional context

Pinned as a KNOWN-DEFECT characterization test, RT-27, in ResourceTypeDetailPage.test.tsx (nicolejms#1). It asserts the current wrong output, so correcting the filters will fail it — which is the intended signal that this is fixed.

Found while writing coverage for ResourceTypeDetailPage, which was the single largest coverage gap in the repository at ~20% statements.