Put the pnpm workspace at client/, with galaxy-api-client as the first member

[dannon]

Follow-up to #22514. That PR settled how the Galaxy client gets distributed to operators -- it ships via the galaxy-web-client Python wheel, not npm -- and as part of that it deleted the repo-root package.json that used to drive npm install @galaxyproject/galaxy-client. With that gone, there's no reason to keep the pnpm workspace at the repo root either. This PR puts it where it actually belongs: inside client/.

Along the way, it does the work the standalone client-api/ package has been waiting for since it landed -- makes it a real workspace member instead of a peer-of-client pretending to be separate, and flips the schema relationship so the OpenAPI types are canonical inside the package rather than re-exported from the main client via a symlink.

What changes

• The workspace lives at client/ now. client/pnpm-workspace.yaml declares packages/*; a single client/pnpm-lock.yaml covers everything; the old per-package client-api/pnpm-lock.yaml is gone.
• client-api/ moved to client/packages/api-client/. It's the first workspace member, consumed by the main client as a workspace:* dep.
• OpenAPI schema is now canonical in the package. client/src/api/schema/index.ts is a one-line re-export from @galaxyproject/galaxy-api-client; the 48K-line schema.ts lives inside the package; the old symlink from api-client back into client/src/api/ is gone. make update-client-api-schema regenerates into the new location.
• Dev-mode ergonomics: client/vite.config.mjs uses a conditional resolve.alias so during vite serve imports of @galaxyproject/galaxy-api-client resolve directly to package source -- edits HMR in the main client without a rebuild. Production builds still consume the package via its package.json exports / dist/.
• postinstall on client/package.json runs pnpm --filter @galaxyproject/galaxy-api-client run build so dist/ is present for vue-tsc and production vite build.
• CI is simplified to workspace-filtered invocations (pnpm --filter @galaxyproject/galaxy-api-client ...).
• client/packages/README.md documents the layout, the criteria for adding a package, and common ops.

Commits, for atomic review

1. Move client-api/ to client/packages/api-client/ -- mechanical relocation. Package remains a standalone pnpm project at the new path with its own lockfile; no workspace tooling yet.
2. Adopt into the client pnpm workspace -- single client/pnpm-lock.yaml; CI simplified to pnpm --filter.
3. Invert API types -- schema canonical in api-client; client re-exports; symlink removed; postinstall wired; Makefile target updated.
4. Dev-mode source alias -- conditional resolve.alias in client/vite.config.mjs.

(Plus a docs commit adding client/packages/README.md and the cross-link from client/README.md.)

Not in this PR, but stacked on top

A follow-up PR relocates the G-prefixed base components (GButton, GLink, GModal, GHeading, GTabs, GTooltip, GOverlay, GTip, GForm*, etc.) into a second workspace package at client/packages/ui/ as @galaxyproject/galaxy-ui. That package stays internal (`"private": true`) for now -- it exists as an architectural boundary and a migration target for #21956 (Bootstrap-Vue replacement) and the eventual Vue 3 work. It flips to published when the interface stabilizes on Vue 3.

Issue #13336 captures the revised scope -- earlier framings listed utils / composables as packages too, but on closer review neither cleared the bar (no external consumer story, plenty of existing npm substitutes, and no useful internal forcing function). So the full decomposition is just these two package boundaries: this PR plus the `galaxy-ui` follow-up.

No runtime or API behavior change in the main client.

Test plan

• `pnpm install --frozen-lockfile` succeeds; postinstall builds api-client
• `pnpm --filter @galaxyproject/galaxy-api-client test` -- 9/9 pass
• `pnpm type-check`, `pnpm eslint --quiet`, `pnpm format-check` all clean
• `make client` produces a clean production bundle
• `make update-client-api-schema` regenerates into the new canonical location and leaves the tree clean
• `make client-dev-server` boots clean
• Galaxy serves normally in dev (HMR picks up package source edits) and from the prebuilt wheel path

[mvdbeek]

Do we need to update the publishing procedure and workflows too ?

[dannon]

Do we need to update the publishing procedure and workflows too?

Good catch -- yes. Just pushed a fix.

The issue: client/package.json now has @galaxyproject/galaxy-api-client at workspace:* plus a postinstall that runs pnpm --filter to build it. npm publish doesn't rewrite the workspace protocol, so the published tarball would carry the literal workspace:* and break downstream installs. The postinstall is also workspace-only -- if it ships, consumers' npm install would fail when pnpm tries to filter outside any workspace.

The fix in publish_artifacts.yaml swaps the publish client step to pnpm publish (which substitutes the real version) and runs npm pkg delete scripts.postinstall first to strip the workspace-only script. Verified locally with pnpm pack -- tarball is clean.

The client-api publish step is unchanged since it has no workspace deps.

Worth flagging: with #22514 landing, the @galaxyproject/galaxy-client npm publish is effectively redundant with the galaxy-web-client PyPI wheel that common_startup.sh and install-client now consume. I left a TODO in the workflow to drop the build+publish steps post-26.1 once we've confirmed no external consumers depend on the npm package.

[mvdbeek]

Can you resolve the conflict ?