select first orc as default when default is delegated

[CamronStaley]

🔗 Related Issues

📋 What changes are proposed in this pull request?

If we have multiple orcs, immediate execution, and default to delegated we don't currently select an orc as the default instead it goes to "execute". This fixes that by defaulting to the first orc listed

🧪 How is this patch tested? If it is not, please explain why.

deployed in teams here: https://camron.ephem.fiftyone.ai/datasets/quickstart/samples

📝 Release Notes

Is this a user-facing change that should be mentioned in the release notes?

• No. You can skip the rest of this section.
• Yes. Give a description of this change to be included in the release
  notes for FiftyOne users.

If your operator defines "default_choice_to_delegated" as true and allows immediate execution now the UI will automatically select an orc to schedule on instead of "execute immediately".

What areas of FiftyOne does this PR affect?

• App: FiftyOne application changes
• Build: Build and test infrastructure changes
• Core: Core fiftyone Python library changes
• Documentation: FiftyOne documentation changes
• Other

Summary by CodeRabbit

• Bug Fixes
  • Fixed scheduling options to correctly default to the first available orchestrator when scheduling is enabled.

[coderabbitai]

Walkthrough

The change modifies how default options are generated for orchestrator schedules in the prompt submission logic. Instead of iterating directly over availableOrchestrators, the code now uses .entries() to access both values and indices. The first orchestrator's option is conditionally marked as default based on the defaultToSchedule flag, whereas previously no per-orchestrator default designation was applied.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately reflects the main change: selecting the first orchestrator as default when delegated scheduling is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	PR description covers key sections but related issues section is empty and lacks concrete test details.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/select-orc-default

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/packages/operators/src/state.ts`:
- Around line 326-334: The loop is iterating over
execDetails.executionOptions.availableOrchestrators instead of the
already-defined availableOrchestrators variable; update the for...of loop to
iterate over availableOrchestrators (preserving the destructuring of [index,
orc]) so the block that pushes into options still uses the same single source of
truth (keep the defaultToSchedule && index === 0 logic and references to orc.id
and orc.instanceID intact); this makes the code consistent with
hasAvailableOrchestrators and the earlier variable declaration.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 522410e1-7aca-482d-92c0-8fce11a03017

📥 Commits

Reviewing files that changed from the base of the PR and between 16c8c38 and 377c94f.

📒 Files selected for processing (1)

• app/packages/operators/src/state.ts

[kaixi-wang]

lgtm, didn't test