Lint: fix credo error

[josephjclark]

Our lint tests are failing for a bunch of reasons, but one of them is this credo error:

One Enum.reject/2 is more efficient than Enum.reject/2 |> ┃ Enum.reject/2

Looking at the code in question I'm not too worried about performance, I think the code is clearer using two iterations.

Claude says this:

our current code has a comment on line 907-911 explaining why target-only-added-after-fork workflows get dropped, and the two separate rejects read as two distinct filtering concerns ("drop ones still in the sandbox" then "drop ones added after the fork"). Merging them into a single or slightly blurs those two intents. On a list of workflows the efficiency gain is negligible.

On that basis I've disabled credo for that line. Open to suggestions but I think this is quite reasonable.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our
Responsible AI Policy

[github-actions]

Security Review ✅

• S0 (project scoping): N/A, diff only adds a credo:disable-for-next-line comment above an existing Enum.reject/2 call in lib/lightning_web/live/sandbox_live/index.ex:914; no queries or data access changed.
• S1 (authorization): N/A, no new or modified handlers, controllers, or LiveView events.
• S2 (audit trail): N/A, no writes to project/instance configuration resources.

[elias-ba]

Pushed a small alternative @josephjclark: folded the two rejects into one pass with or so credo passes for real, rather than suppressing it.

[elias-ba]

Hey @josephjclark, I pushed another commit directly here to fix a flaky JS test that was failing CI on this PR. Nothing to do with your change, just a pre-existing test in Header.test.tsx that leaked state between tests and tripped under certain run orders. Added the per-test teardown the sibling file already does, and ran the suite shuffled many times to confirm it's stable.

[josephjclark]

@elias-ba that commit should have been a different PR really! Let me check and merge.

[josephjclark]

Is this change expected?