Epic: Operator-facing configurability — portable doctrine paths, .kitty.env config, and release-channel opt-in

## Problem

Operator-facing configuration and install/opt-in friction is spread across three
areas that together make Spec Kitty harder to install, adopt, and keep using —
for operators, our own dev team, and early adopters / external contributors.

Concrete pain points:

- **SaaS opt-in is hand-wired per shell.** Opting into hosted SaaS sync currently
requires manually exporting env vars on *every* shell session, e.g.:
```bash
export SPEC_KITTY_ENABLE_SAAS_SYNC=1
export SPEC_KITTY_SAAS_URL=https://app.spec-kitty.ai
```
There is no config-referenced, persisted way to carry these.
- **Committed charter files carry absolute machine paths.** Charter generation
writes host-absolute `source_path` entries into
`.kittify/charter/charter.yaml`, so a committed charter is non-portable across
machines and checkouts.
- **No smooth way to catfood rc / internal builds.** There is no opt-in channel
for release candidates or internal builds; `spec-kitty upgrade --agent-check`
filters pre-releases, so an operator already running an rc sees stable-only and
cannot smoothly upgrade to / stay on the rc line.

## Goal

Make **install**, **SaaS opt-in**, and **rc-catfooding** smooth and portable:

- Portable, machine-independent doctrine/charter paths.
- A persisted, config-referenced way to opt into SaaS sync (no per-shell exports).
- A default-off opt-in channel for unstable/rc/internal releases.

All three must be honored by the migration / upgrade / doctor entry points and
documented in user-facing docs — not just wired into runtime and left undiscoverable.

## Children

_All three are native GitHub sub-issues._

1. **T1** — #3494 — Portable charter/doctrine `source_path` resolution via canonical `SPEC_KITTY_PACKS_ROOT`
2. **T2** — #3495 — Smooth SaaS opt-in: `.kitty.env` file referenced from `config.yaml`, loaded CLI-wide
3. **T3** — #3496 — Opt-in unstable/rc release channel (consumer slice: default-off channel + prerelease-aware update-checker + `--pre` install wiring). **Narrow consumer slice only** — the producer half (automatic weekly rc cadence, tag shape, release-workflow changes, rc-tolerant migration chains) stays in the pre-existing umbrella **#3047** and is out of this epic's scope.

## Sequencing (weakly-coupled — three independent sub-missions)

The three themes are only weakly coupled, so deliver them as independent
sub-missions rather than one entangled effort:

- **A — T1 (#3494)** (portable paths): lowest risk, **no migration required**; ship first.
- **B — T2 (#3495)** (`.kitty.env`): carries **migration + secret-handling risk** — the
only one of the three that needs a migration (which must auto-run and be
idempotent; see #3381).
- **C — T3 (#3496)** (rc consumer opt-in): no new migration; coordinate with the
producer half in **#3047** at the "an rc is published and PEP 440-tagged" contract.

## Related epics / issues (related, NOT duplicated)

- **#3047** — *(T3 producer half)* Automatic weekly release-candidate cuts: rc
cadence, prerelease-aware update-checker, rc-tolerant migration chains (OPEN,
P1). Owns the **producer side** — automatic rc cadence, tag shape, release
workflow, and rc-tolerant migration chains. T3 (#3496) is the narrow **consumer
slice** (default-off channel + prerelease-aware update-checker + `--pre` install
wiring; concrete symptom: `spec-kitty upgrade --agent-check` reports `3.2.5` to
an operator running `3.2.6rc2`). The two meet at the "an rc is published and PEP
440-tagged" contract; do not duplicate #3047's producer scope inside #3496.
- **#3381** — *(T2 adjacency)* Hosted-sync consent: FR-019 migration silently
dropped legacy opt-ins; uuid backfill never auto-runs (OPEN, P1). Directly
informs T2's migration discipline: the `.kitty.env` migration must auto-run and
be idempotent, never gated behind a diagnostic command.
- **#2652** — EPIC: `specify_cli/missions` retirement (activation-driven availability,
single canonical mission-type source). Tangential; shares the "single canonical
authority" discipline this epic's Child 1 leans on. Not overlapping in scope.
- **#2519** — Epic: Charter authoring & lifecycle robustness. **Related** — Child 1
touches charter generation (`source_path` emit). Portability of committed charter
files is a lifecycle-robustness concern; link as related, do not fold.
- **#3251** — Follow-ups from #3246 (rc35-migration seed authority, importlib.metadata
except-audit, **PACKS_ROOT fail-closed decision**). **Direct overlap on Child 1's
surface** — item 3 concerns `src/kernel/paths.py` `SPEC_KITTY_PACKS_ROOT` resolution
(fail-closed vs DR-1 parity on a set-but-invalid override). Child 1 delegates the
portable emit to that same canonical authority, so the two must stay coordinated;
linked as related, not duplicated.
- **#3022** — Extract built-in doctrine packs into `spec-kitty-packs-open` (dogfood our
own pack distribution). **Related context** — the relocation of built-in doctrine to
`packs/built-in/` is the root cause behind Child 1's stale normalizer; the eventual
pack-extraction shape may change where `source_path` should point. Coordinate, do not
duplicate.

## Constraints

- **No version / milestone prescription** — the PO assigns those.
- Honor the DR-1 single-env-read discipline at the kernel floor for any new env vars.

Start with child issues #3494, #3495, and #3496 rather than treating this epic as one implementation. Read src/kernel/paths.py and the config.yaml and .kittify/charter/charter.yaml references, then inspect the upgrade --agent-check entry point. Done means each child’s scoped behavior is implemented, migration and upgrade/doctor entry points honor it, and user-facing documentation explains the configuration and release-channel options.

Written by the indexing model from the issue text.