test(desktop): isolate FloatingBar notification owner authority

[aryanorastar]

What changed and why

The same defect #12192 fixes in RewindCaptureExclusionGenerationTests, in a suite #12039 does not name. I found it while checking whether the other suites in that issue shared a root cause — three of them don't, this one does.

Both owner-seeding tests wrote auth_userId directly:

defaults.set(owner, forKey: DefaultsKey.authUserId.rawValue)

Runtime owner authorization is process-wide and deliberately fails closed on exactly that write — RuntimeOwnerIdentity.swift:51:

} else if self.ownerID != normalized {
  revokeUnexpectedOwnerMismatch()
  return nil
}

Once any earlier owner-bound suite has bootstrapped a different owner, the raw write revokes the authority and it stays revoked without a real beginTransition/endTransition pair. So the outcome depended on which suite ran first.

Both tests now establish their owner through RuntimeOwnerAuthorityTestFixture, crossing the same serialized transition boundary production uses. Restore happens in tearDown rather than a defer — a defer can't await, and more importantly a failed assertion must not leave the process-wide authority revoked for whatever runs next, which is the contamination this is fixing. Adopting the fixture also enrolls the suite in the runner's derived owner-isolation cluster, since swift-test-suites.sh greps for that symbol.

How it was verified

I checked the guard actually does the work rather than assuming it. Identical command, same three owner-bound suites, only the fix differing:

before:  Executed 28 tests, with 1 failure
         FloatingBarNotificationPreviewPolicyTests.swift:218: error:
         XCTAssertEqual failed: ("rejectedOwnerChange") is not equal to ("suppressed")

after:   Executed 28 tests, with 0 failures

xcrun swift test --package-path Desktop \
  --filter 'CaptureScreenToolTests|FloatingBarNotificationPreviewPolicyTests|ChatToolExecutorPolicyTests'

In isolation the suite passes both before and after (19/19) — which is exactly why the flake read as nondeterministic and why running it alone never reproduced it.

xcrun swift build -c debug --package-path Desktop clean.

Worth noting the symptom is not where I first expected it. I predicted XCTUnwrap(RuntimeOwnerIdentity.currentOwnerId()) would throw on a nil owner; it doesn't — currentOwnerId() returns fine and the revocation surfaces later at the delivery gate as rejectedOwnerChange. Same root cause, different surfacing point, and the rejectedOwnerChange payload is precisely the "production error payload that looks like a real defect" the failure class describes.

This is test-harness isolation only; no production code is touched and there is no user-facing path to exercise.

Product invariants affected

none

Relationship to the other #12039 suites

ChatTranscriptGestureHarnessTests, KernelTurnRecordedProjectionTests, and SuggestedTasksStoreTests have no authUserId writes and don't use the fixture, so they flake for some other reason. This PR does not address them and I have not diagnosed them.

Failure-Class: FC-hand-listed-test-isolation-membership

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Git-on-my-level]

Verified against the current head — this checks out cleanly, and the root-cause diagnosis is accurate.

• FloatingBarNotificationPreviewPolicyTests.swift is the only changed file, and the fix is exactly what the flake class in Desktop Swift Static & Test Contracts: four different test suites flaked in one afternoon #12039 calls for: both owner-seeding tests previously wrote auth_userId directly into UserDefaults, which trips the fail-closed owner-mismatch guard in RuntimeOwnerIdentity.capture(...) (RuntimeOwnerIdentity.swift:51-53) once an earlier owner-bound suite has bootstrapped a different owner — so the outcome depended on suite order.
• The new setUp/tearDown pair adopting RuntimeOwnerAuthorityTestFixture matches the fixture's contract in RuntimeOwnerAuthorityTestSupport.swift: establish(authOwnerID:) crosses the same performEffectiveOwnerTransition boundary production uses, and restore() re-crosses it instead of raw-writing defaults. Moving owner restoration out of defer into tearDown is the right call — defer can't await, and more importantly a failed assertion must not leave the process-wide authority revoked for whatever runs next.
• Confirmed side benefit: swift-test-suites.sh derives its owner-isolation cluster by grepping for RuntimeOwnerAuthorityTestFixture, so this suite is now serialized with the other owner-bound suites automatically, matching the canonical prevention recorded in the hand-listed-test-isolation-membership failure class.
• Dropping authUserId/automationOwnerOverride from pinnedKeys is consistent — the fixture now owns those keys' lifecycle.

The before/after run transcript in the description (1 failure → 0 failures across the three owner-bound suites) is a credible verification of the guard doing the work. Thanks for tracing this through the guard mechanism rather than just pinning more keys — it pairs nicely with #12192 for the Rewind suite. Leaving for human maintainer review before merge.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.