[shuv1337]

Post-cutover backlog, item (a): executor-v2 apps call returned 403 on every call for a device-code (kyle@) CLI profile, while the same HTTP requests with that profile's token worked.

Cause

The CLI produced the 403 itself; the host never refused anything.

• executor apps login saves the organization's ID but prints Connected to <host> as @<slug>, so people pass the slug as --organization.
• access() in packages/app-management/src/cli.ts compared the flag with the saved ID only. A slug didn't match, so the CLI stopped with "Forbidden (HTTP 403)" without sending a request.
• That explains why the manual requests worked: the host accepts either a slug or an ID.
• This affects every executor apps command given --organization <slug>, not only call.
• Inference, not checked: I didn't inspect Kyle's actual profile. If his failing command didn't pass --organization, this isn't his cause.

Fix

access() accepts the session's own ID or saved slug and sends the stored ID. Any other organization is passed to the host, which refuses it with a real OrganizationForbidden. No authorization is loosened. The --organization help now says "ID or slug", and there's a changeset.

Tests

New appsCliCallDeviceLogin scenario in apps-cli-call.spec.ts (self-host):

• the owner and a member sign in through the device-code flow;
• the owner's list and call work with --organization <slug> and with the ID;
• an unknown organization gets the host's OrganizationForbidden 403;
• the member is refused (403, the tool doesn't run) until the app is shared, then succeeds.

It fails before the fix, at the slug step. On self-host, both apps-cli-call scenarios and four device-login scenarios pass. bun run check passes.

apps-cli-call.spec.ts
device-login.spec.ts
app-git-remotes.spec.ts