feat: browser-native Globus Transfer + plugin detection

[scttfrdmn]

Phase 3 of the parity/advisor/execution plan. Data movement in and out of a
launched instance, plus the ability to say what's deployed on one — with an
honest split between what a browser can do and what belongs to the CLI.

Globus does not need a local machine

This corrects an earlier claim of mine, and the correction is what makes the
phase possible. The globus-personal-endpoint plugin needs globus whoami
locally, but that plugin wraps Globus Connect Personal specifically. Globus
Transfer is a REST API over managed collections — an HPC DTN, an S3
collection — and it is fully CORS-enabled. Preflighted live from
Origin: https://spore.host:

endpoint	ACAO
transfer.api.globus.org/v0.10/endpoint_search	*
transfer.api.globus.org/v0.10/task_list	*
auth.globus.org/v2/oauth2/token	*

So src/transfer/globus.ts is fetch only — no SDK — mirroring how
src/auth/globus.ts already talks to Globus.

It reuses the sign-in we already have. The transfer scope goes into the
requested scopes, and completeLogin already walks the per-resource-server
other_tokens array, so the Transfer token comes back from the same sign-in
that produces the STS id_token. GlobusTokens grows a transferToken; there
is no second auth flow.

submit_transfer fetches a submission_id first, as the API requires — that's
what makes a retried submit idempotent rather than moving the data twice.

The browser's job with plugins is detection, not execution

spore-sync (mutagen), rclone, tailscale, gha-runner and Globus Connect Personal
are launched by the CLI. That's their proper home, and the web view should not
reimplement them. What the web view must do is report what's deployed, and the
wire already supports it: spawn's recordPluginProvenanceTag writes a
spore:plugin:<name> EC2 tag valued
version=…;sha256=…;commit=…;verify=signature|manifest|none, and
DescribeInstances is already in the browser's reach.

parsePluginTag is pure, and its central property is that an unrecognised or
absent tag yields "unknown" — never a fabricated "not installed". Those are
different claims: one says we couldn't tell, the other asserts a fact about the
instance we have no basis for. Same invariant as Go #63.

This splits the plugin surface three ways, and the split is part of the
deliverable:

	browser can install	browser can detect
7 remote-only (jupyterlab, code-server, rstudio-server, docker, mountpoint-s3, cloudwatch-agent, vscode-tunnel)	yes — pure userdata	yes
Globus Transfer	yes — REST + the existing auth	yes
Globus Connect Personal, spore-sync, rclone, tailscale, gha-runner	no — the CLI's job	yes, via the tag

Reporting that third group as absent would read as "no plugin support in the
browser", which is false.

mountpoint-s3 pairs with Transfer for the other direction — S3-as-filesystem on
the instance, also remote-only. Between them, data moves in and out with zero
locally installed software.

Verification

npm run typecheck clean; 382 tests passing, with no credentials and no
network anywhere:

• the transfer client takes an injected fetch (the convention
  completeLogin already uses), driven through a canned
  submit_transfer → task/<id> polling sequence
• parsePluginTag is pure and round-trips the real Go tag format, including the
  unknown/absent cases

Live Globus transfer moves real data, so it stays a manual, opt-in check —
never CI.

Docs: docs/data-movement.md.