`oo flow open` fails without a locally saved Team although Flow API commands use the server-side default

[Cheerego7]

Summary

After upgrading to oo v1.8.0, an account with no locally saved default Team can successfully create, inspect, and mutate Open Flow resources through the server-side default Team, but oo flow open <flow> fails with:

flow.unexpected: Select a Team before opening the Open Flow Workbench.

This leaves the CLI in an inconsistent state: a Flow can be created and validated, but the same Flow cannot be opened in Workbench until the user explicitly persists a Team locally.

Environment

• oo: 1.8.0 (d8452c73)
• Open Flow command artifact: 0.1.0-alpha.11
• macOS 26.5 (25F71)
• Hosted Open Flow
• Account belongs to multiple Teams but has no locally saved default Team

Reproduction

Starting from an authenticated account whose local account record has no default Team:

oo team current --json

returns:

{"team":null,"teamId":null,"source":null,"status":null}

Then:

oo flow create repro-flow --json
oo flow show repro-flow --json

Both commands succeed. The Flow can also be mutated and checked successfully.

However:

oo flow open repro-flow

fails with:

flow.unexpected: Select a Team before opening the Open Flow Workbench.

Expected behavior

The no-header/server-side-default-Team behavior should be consistent across Control API and Workbench operations.

Preferably, oo flow open should resolve the effective server-side default Team to a concrete Team name before building the Team-scoped Workbench URL. If that is not possible, all hosted Flow commands that can create or mutate state should fail before the mutation with a clear Team-selection error, rather than allowing a Flow to be created and then refusing to open it.

Root-cause evidence

In src/application/commands/team/identity.ts, resolveTeamIdentity() intentionally returns undefined when no local Team selector exists. The module documents that this means no Team header is sent and the gateway applies the account's server-side default Team.

In src/application/commands/flow.ts, cloudRequest() accepts that state: teamIdentityHeaders(undefined) produces no Team headers, so Flow API operations proceed through the gateway default.

But getWorkbenchUrl() requires session.teamName and throws when it is absent:

if (session.teamName === undefined) {
    throw new TypeError("Select a Team before opening the Open Flow Workbench.");
}

The current Workbench test covers only an account with a locally stored Team. There does not appear to be a regression test for the implicit server-side default Team path introduced/clarified by #355.

Impact

• Users upgrading from an older version with no locally persisted Team can create Flows that they cannot immediately open.
• The CLI does not reveal which Team the gateway selected for the successful Flow API mutation.
• The error is surfaced as flow.unexpected, although this is a known configuration/state branch with a concrete remediation.
• Users may select the wrong Team merely to satisfy flow open, after which the newly created Flow may not be visible in that Team-scoped Workbench.

Possible regression guard

Add a hosted Workbench test with an authenticated account that has no team or teamId fields and assert one consistent policy:

1. resolve the gateway's effective default Team and build a valid Workbench deep link; or
2. reject all stateful hosted Flow operations before they reach the gateway.

The test should cover both host.cloudRequest() and host.getWorkbenchUrl() from the same resolved session so the two paths cannot drift again.