. Onboarding ten projects used to cost
  twenty visits to extension.dev/device, one to create each project and
  one to sign in to it, and the ten tokens then expired together and cost
  ten more. This release is the client half and waits on the platform
  deploy that accepts a list. The platform advertises the capability as
  `batchOnboarding` in its login config; against a platform that does
  not, both inputs below refuse the list before a device code is spent
  and name the one-project call to use instead.
- `extension_project_create` takes `projects`, a list of
  `{ project, repo }` entries in one workspace, in place of `project` and
  `repo`. The approval page lists every name. Each project is created by
  its own request and its 7-day token is stored as that project's login,
  so no `extension_auth` call follows. An entry may carry its own
  `displayName`, `description`, `installCommand`, `buildCommand`,
  `outputDirectory`, `browsers` and `outputDirectories`; the same inputs
  at the top level are the default for entries that leave them out.
- The answer has one row per project: created and logged in, created
  with no token (the hint names the batch login to run), refused with the
  platform's own code, unconfirmed when a request got no answer, or not
  attempted. A refusal about one project (a name taken, a reserved slug)
  does not stop the list. A refusal about the approval (an expired grant,
  the hourly limit, the plan's project limit, a missing GitHub App
  installation) stops it, and every project not reached still gets a row
  saying so.
- A list takes a few calls: creating a project is slow, so while
  projects remain the answer is `status: "creating"` with the same
  `deviceCode` to call again. The provisioning grant is held in the
  server's memory for its 15 minutes and is never written to disk or
  returned; if the server restarts mid-list the projects already created
  stay created and the rest need a new approval.
- One approval creates at most 10 projects, because the platform creates
  at most 10 per hour for one approving account; the next 10 can start
  in a new call once that limit allows. The cap is read from the
  platform's login config (`createProjectsPerApproval`), with 10 as the
  fallback when the platform states no usable number. A longer create
  list is refused before any approval is asked for, with that reason; it
  is never split silently.
- `extension_auth` with `action: "login"` takes `projects`, a list of up
  to 20 `<workspace>/<project>` names of existing projects in one
  workspace (the platform's `loginProjectsPerApproval`), in place of
  `project`. One approval stores one token per
  project, which is also how a set of logins that expire together is
  renewed. One missing project refuses the whole list and stores
  nothing. The call that completes a batch login can take up to a
  minute.
- Both lists are checked before a device code is spent, by the
  platform's own rules: one workspace, 1 to 20 names, no name twice, and
  each project by its exact slug (lowercase letters and digits joined by
  single dashes, at most 48 characters). The refusal names the entry.
- A batch login or create does not change which login is the default.
  A single login still does.
- A server started with `--project` refuses a list that names any other
  project, the same refusal a single call gets, and takes a list of the
  pinned project alone. A list on `logout` or `status` is refused rather
  than ignored.
- `extension_project_create` no longer lists `project` and `repo` as
  required in its schema, since a list replaces them. A call with
  neither form is still refused, by the tool.
- `extension_publish` with `project` now describes the project it was
  called for. The token was already picked
  by `project`, but `registryUrl`, and the build index behind a missing
  `buildSha`, `version` or `builtAt`, came from the most recent login, so
  with several logins stored a publish for one project could return
  another project's registry address and fill its build details from
  another project's builds. The same slip is fixed in
  `extension_release_promote` (the builds page, the channel list and the
  public URLs it returns) and in the `extension_submit` dry run (the
  console page it names). `extension_shares` and `extension_preview_web`
  were checked and did not have it.
- A private project's registry data is read with the login stored for
  that project. It used to be asked with the most recent login, which
  gave up on a mismatch and reported the builds as missing.
- `extension_release_status` reads a `project` given as
  `<workspace>/<project>`, the form every other tool takes. It used to
  join the pair to the active login's workspace and ask the registry for
  an address that names no project, which is also what a server started
  with `--project` sent on every call.