Design artifacts misfile when project spans multiple repos

## Problem

gstack's artifact filing (`~/.gstack/projects/$SLUG/`) derives the slug from the current git repo. This assumes project = repo. When a project spans multiple repos, design docs, test plans, and review results have no stable home.

### Concrete example

A platform service project spans 4 repos:
- Application service (Go backend + CLI + container image)
- Helm chart for deployment
- Terraform module
- Infrastructure repo (Terraform for environment-specific resources)

One design doc covers the full system. `/office-hours` produced it, `/plan-ceo-review` reviewed it, `/plan-eng-review` reviewed it. All three sessions ran from a working directory that wasn't any of the project repos (skills were vendored locally in an unrelated directory), so the slug resolved to that directory's repo name and all artifacts landed under the wrong project.

When implementation starts across the actual repos, each repo resolves a different slug. No session will find the design doc or review history unless pointed at it by explicit path.

### What breaks

- `/plan-eng-review` design doc check (`ls ~/.gstack/projects/$SLUG/*-design-*.md`) finds nothing when the slug doesn't match where the doc was filed
- Review readiness dashboard (`gstack-review-read`) is global (not slug-scoped), so review status works, but test plans and design docs are orphaned
- `/office-hours` saves a design doc under one slug; `/plan-eng-review` in a different repo can't find it

### Why this happens

The slug detection chain is:
1. `remote-slug` (GitHub remote name)
2. `basename $(git rev-parse --show-toplevel)` (repo directory name)
3. `basename $(pwd)` (fallback)

All three are repo-scoped. There's no concept of a project that groups multiple repos.

Start by tracing the slug detection chain described in the issue and how /office-hours, /plan-ceo-review, /plan-eng-review, and gstack-review-read locate artifacts. Compare behavior when sessions run from unrelated directories or different repositories. Done should include a defined project identity that lets design docs, test plans, and review history remain discoverable across the project's repositories.

Written by the indexing model from the issue text.