docs: clarify account provisioning requirement for first-time CLI auth

[DannyBaanks]

Summary

Clarifies the current first-time-user requirement in the CLI installation/auth
documentation.

Issue #103 demonstrates that a new user can successfully reach the brokered
authentication flow but still be unable to complete onboarding when no account
has been provisioned.

What Changed

Added a short note to the two public install guides:

1. docs/install/install-guide.md — under the Authentication section
2. docs/install/CALL-E-installation-guide.md — mirrored copy, since this file
   is the stable public entry point

Both now state: \calle auth login\ authenticates an existing account. If
no account has been provisioned, the credential-only dashboard login page has
no visible signup path. Users should see #103 for the current supported
new-user path.

Scope

• Documentation only
• No behavior change, no API change, no auth code touched
• No claim is made that the production onboarding fix (issue New hackathon users cannot complete account provisioning: brokered auth redirects to login-only dashboard with no signup path #103, assigned P1)
  is resolved by this

Evidence

• Issue New hackathon users cannot complete account provisioning: brokered auth redirects to login-only dashboard with no signup path #103 (P1 triage): the broker/session/return-url plumbing is verified;
  what is missing is provisioning at the dashboard boundary
• Reproduction sequences and evidence dossier are in
  CAllEE AUTH RESCUE
  (via the \DannyBaanks/CALL-E-AUTH-RESCUE-HACKATHON\ comment thread)

Release decision

No release needed — docs-only, no package published output affected.

Refs #103

[Ray-56]

[P1] This guidance is already stale and would direct first-time users away from a working onboarding route.

The exact head says the dashboard "accepts only Account/Password credentials and shows no visible signup path." The currently deployed login bundle now renders Continue with Google, includes the broker/MCP return parameters in the OAuth request, and describes preparing the user's workspace after sign-in. Issue #105 also reports testing after the provisioning fix. Publishing the old outage state in the stable installation guide would therefore tell new users that they cannot onboard when the supported OAuth path is available.

Please replace this block with the current, verified first-time-user flow: select Continue with Google, finish account/workspace provisioning, return to the original broker session, and complete calle auth login. Validate the full flow from an anonymous browser session, including the 20-call entitlement and the CLI token exchange. Keep a troubleshooting note for failures, but do not use an open Issue as the source of supported installation steps or claim that a product route "is being added" without a maintained source.

Also follow docs/documentation-maintenance.md: put the canonical instruction in one install document, add a sync-with pointer where duplication is required, and reconcile related public claims such as README.md so they do not contradict the supported flow.

CI for 19f774e is action_required with zero jobs. I ran the exact head in an isolated checkout: pnpm check, pnpm test, and pnpm pack:dry-run all pass, but those checks cannot validate this live product-state claim.

Release decision: no package release is needed if the correction remains limited to the root installation docs. If packaged README/skill guidance changes, use patch changesets for the affected published packages.

[DannyBaanks]

Updated per @Ray-56's #103 status note: replaced the stale 'no visible signup path' wording with the verified first-time-user flow (brokered sign-in -> Continue with Google -> workspace provisioning -> return to broker -> \calle auth login\ token exchange). The earlier credential-only page is kept as a troubleshooting pointer to #103, which remains OPEN pending the anonymous-user regression check.

Local validation on this branch (commit 91d350e):

• \pnpm check\ PASS
• \pnpm test\ PASS (unit + e2e, CLI package)
• \pnpm pack:dry-run\ script FAILS on Windows cmd only because it uses \mktemp/bash syntax; the equivalent \pnpm pack --pack-destination \ succeeds (tarball builds cleanly).

NOTE: I did NOT claim anonymous-E2E completion myself — that needs a fresh account, flagged as pending in #103.