feat: add scoped setup installs and local-first runtime resolution

[AliFozooni]

Summary

This turns setup from a single global-install assumption into a scoped install + runtime-resolution model.

This is intentionally broader than a --local flag: setup, generated SKILL.md files, and the Codex sidecar layout all need to agree on the same install root or a project-local install only half works.

Why

Issue #229 asks for true isolation at setup so gstack can be evaluated inside one workspace without writing into a global profile.

This also fixes the Codex root collision in #261, where setup could rewrite ~/.codex/skills/gstack away from the repo root.

The larger direction is consistent with the host docs already treating project-scoped and personal-scoped agent assets as separate concepts:

• Anthropic documents project commands under .claude/... and personal commands under ~/.claude/...: Slash Commands in the SDK
• OpenAI documents Codex as running in isolated environments guided by repo-local AGENTS.md: Introducing Codex

What changed

• add ./setup --scope auto|user|workspace
• add ./setup --project-root <path> for explicit workspace installs
• allow user-scoped installs from arbitrary checkouts into ~/.claude/skills/ and ~/.codex/skills/
• allow workspace-scoped installs into a single repo’s .claude/skills/ and .agents/skills/
• stop link_codex_skill_dirs() from overwriting the root gstack runtime entry with the generated root skill
• build workspace Codex installs as a managed sidecar that exposes the root skill plus runtime assets/docs instead of aliasing the generated skill directory itself
• make generated SKILL.md files resolve runtime commands and review docs from project-local roots first, then fall back to the global install
• preserve $HOME/.codex/skills/gstack in generated upgrade flows instead of rewriting it to $HOME/.agents/skills/gstack

Testing

• bash -n setup
• PATH="/tmp/bun-install/bin:$PATH" /tmp/bun-install/bin/bun test test/gen-skill-docs.test.ts test/setup.test.ts

Closes #229
Closes #261
Refs #289

[loocor]

Hi @AliFozooni, I’ve been trying to think through how gstack can support more hosts and runtimes without each integration having to re-solve install scope and path resolution on its own, so this PR is very relevant to a problem I’ve been looking at.

What feels especially useful here is that it makes scoped setup and local-first resolution much more concrete. To me, that suggests install scope and runtime resolution may want to be treated as first-class concepts, rather than just incidental setup details.

I may be missing some context or constraints here, so please take this as a tentative observation rather than a strong architectural claim. But this does seem like the kind of groundwork that future host-specific work could build on, instead of each runtime having to handle global-vs-local behavior separately.

I’d like to reference this in RFC #289 for exactly that reason. If that matches how you’re thinking about this PR, I’d really value your feedback. And if there are constraints here that make that framing incomplete, I’d be very interested to understand them better.