Conductor Quick Start gstack template fails when generated repo has unborn HEAD

## Summary

Conductor Quick Start can fail when creating a new project from the `gstack` template because the setup/build path assumes `git rev-parse HEAD` works. In a brand-new generated repo before the first commit exists, `HEAD` is unborn, so `git rev-parse HEAD` exits `128` and the template setup aborts.

This is separate from the public `garrytan/gstack` repository itself: the upstream repo has a valid `main` HEAD. The failure is triggered by the generated Conductor workspace state during bootstrapping.

## Observed Error

From Conductor while creating a new Quick Start project named `test` at `/Users/jonas/conductor/repos` with the `gstack` template:

```text
Installing gstack...
error: script "build" exited with code 128
'git [...] -- [...]'
Use '--' to separate paths from revisions, like this:
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Node server bundle ready: /Users/jonas/conductor/repos/test/.claude/skills/gstack/browse/dist/server-node.mjs
```

## Likely Setup Path

Current `main` appears to route Conductor setup like this:

- `conductor.json` runs `bin/dev-setup`
- `bin/dev-setup` creates `.claude/skills/gstack -> repo root`
- `bin/dev-setup` calls `.claude/skills/gstack/setup`
- `setup` runs `bun run build` when compiled browse output is missing or stale
- `package.json` writes `git rev-parse HEAD` into these version files:
- `browse/dist/.version`
- `design/dist/.version`
- `make-pdf/dist/.version`

The hard failure is here in the `build` script:

```json
"build": "... && git rev-parse HEAD > browse/dist/.version && git rev-parse HEAD > design/dist/.version && git rev-parse HEAD > make-pdf/dist/.version && ..."
```

## Reproduction Mechanism

I reproduced the same Git failure mode locally by creating a new parent Git repo with no commits, then placing a gstack copy under `.claude/skills/gstack` without its own `.git` metadata. From inside that directory:

```bash
git rev-parse HEAD
```

returns:

```text
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git [...] -- [...]'
```

That matches the Conductor screenshot error and explains why a normal `git clone` of `garrytan/gstack` does not reproduce the issue: a normal clone has a resolved `HEAD`, while Conductor's generated repo can be in an unborn-HEAD state before the initial commit.

## Suggested Fix

Make the build version fallback tolerate unborn Git repos. For example, centralize the version resolution once and write the fallback to all version files:

```sh
GSTACK_BUILD_VERSION="$(git rev-parse HEAD 2>/dev/null || printf unknown)"
printf '%s\n' "$GSTACK_BUILD_VERSION" > browse/dist/.version
printf '%s\n' "$GSTACK_BUILD_VERSION" > design/dist/.version
printf '%s\n' "$GSTACK_BUILD_VERSION" > make-pdf/dist/.version
```

Or inline the same fallback in `package.json` if keeping the build script single-line is preferred:

```sh
(git rev-parse HEAD 2>/dev/null || echo unknown) > browse/dist/.version
(git rev-parse HEAD 2>/dev/null || echo unknown) > design/dist/.version
(git rev-parse HEAD 2>/dev/null || echo unknown) > make-pdf/dist/.version
```

This should preserve normal cloned-repo behavior while allowing Conductor/new-repo bootstrapping before the first commit exists.

## Workaround

Before setup runs, create an initial commit in the generated workspace:

```bash
git add -A
git commit -m "Initial commit"
bin/dev-setup
```

If there is nothing to commit, an empty commit should be enough to create `HEAD`:

```bash
git commit --allow-empty -m "Initialize workspace"
bin/dev-setup
```