Demo B: third registered claim target for the row-6 arbitration receipt

Context

The tear-out portability matrix's row 6 (multi-window targeting / claim-protocol identity binding) is honestly blocked on a design authority, not a test — recorded in the living ledger (TearOutPortabilityMatrix.md footnote ⁷, 2026-07-19) after macOS row 4 landed PASS_NATIVE (PR #15589). The matrix will not simulate the cell; this ticket owns the production/design prerequisite.

Live latest-open sweep: newest 20 open issues at 2026-07-19T20:35Z; no equivalent. A2A in-flight sweep: no competing claim.

The Problem

Row 6's required receipt: with at least three windows, at most one target exposes one menu and one preview for the gesture; identity remains stable — measured through the merged G3 workspace-set claim protocol (PR #15465). Today's Demo B topology cannot host that receipt honestly:

• Three physical windows exist, but only two registered workspaces (the main workspace + one registered popup claimant).
• The physical tear-out vessel is not a DockCrossWindowParticipation target; counting it as a third claimant would produce a false receipt (Emmy's preserved RED control in the ledger: two registered workspaces vs three physical windows, the vessel's live windowId colliding with the workspace target's).

A third page opened merely to be counted is a vacuous witness. The cell needs a third registered claim target — real workspace-set composition.

The Architectural Reality

• The claim protocol itself is merged and unit-proven (PR #15465, G3 arbitration) — the missing piece is a third registered claimant, not the protocol.
• The competing-vessel composition repair belongs to #15396 (explicitly not absorbed by the matrix or this ticket).
• Demo B's workspace-set substrate: AgentOS.childapps.dockdemo.view.DemoBWorkspace + DockWorkspaceSet (merged in the vessel-conversion arc). The natural question: register a third workspace (a second popup claimant, or a workspace-set expansion) so the arbitration receipt has three real registered targets.
• Until this lands, row 6 stays NOT_YET_MEASURED on every platform — the honest hole is the matrix's integrity, not its failure.

The Fix

1. Design the third registered claim target for Demo B (shape decision: a second registered popup workspace vs a workspace-set composition change), with the same fail-closed registration semantics as the existing two.
2. Land it behind the existing registration path (no new protocol; the matrix's cell must measure the MERGED protocol, not a bespoke host).
3. Hand the cell back to the matrix: row 6 executes against the three registered targets (macOS first, then Windows/Linux per their real-desktop receipts).

Acceptance Criteria

• Demo B exposes three registered claim targets through the same registration semantics as the existing two.
• The physical-vs-registered distinction stays honest (the tear-out vessel remains a non-claimant unless the composition design says otherwise — and if it says otherwise, the RED control's identity-collision is addressed explicitly).
• The matrix's row-6 cell becomes executable on macOS without any test-host simulation.
• No change to the G3 claim protocol itself (PR #15465 stays the measured authority).

Out of Scope

• The row-6 test execution itself (the matrix lane owns it once this lands).
• The competing-vessel park/re-show composition (#15396's lane).
• Rows 1–3's named sub-receipts and Windows/Linux desktop sessions.

Related

#15243 (parent matrix) · #15551 (macOS execution child) · PR #15589 (row-4 receipt + footnote ⁷) · PR #15465 (G3 claim protocol) · #15396 (vessel composition, non-owner) · TearOutPortabilityMatrix.md (living ledger).

Origin Session ID: 5a4ad6f9-843f-49d6-aaa1-918a0e476349

Retrieval Hint: row 6 multi-window targeting three registered claim targets Demo B workspace-set claim protocol arbitration matrix