Question: how to set / persist auto-approve duration outside of TUI? (daemon-substrate use case; related to #147)

## Question / Feature request

Is there a way — **outside of the TUI** — to configure the auto-approve duration when using `aac listen --reusable-psk` for a persistent daemon-substrate use case?

## Context

Related to #147 (headless mode / `--no-tui` flag). Even with the interactive TUI approval workflow, I've hit a design gap for background daemon use.

Current behavior:
1. User at TUI: request comes in from paired client → prompt fires:
```
[y] Yes [a] Yes + auto-approve 10m (↑/↓) [n] No
```
2. Arrow keys ↑/↓ adjust the auto-approve duration (empirically each keypress = ~10 min increment)
3. `[a]` approves current request + caches auto-approval for that (session_fingerprint, domain) pair for N minutes

## Findings after investigating

**No non-TUI configuration path found:**
- **No CLI flag** on `aac listen --help` or `aac --help` for setting auto-approve duration
- **No env var** — `strings aac | grep -E "^AAC_"` returns only `AAC_TOKEN`; no `AAC_AUTO_APPROVE_*` or similar
- **No config file** — `~/.access-protocol/` contains only `connection_cache_*.json`, `psk_store_user_client.json`, and `*.key` files. No config file discovered anywhere on the system
- **No persistence** — `connection_cache_user_client.json` `connections[]` entries have keys `[cached_at, last_connected_at, name, remote_fingerprint, transport_state]` — no `auto_approve_until` or similar field. This suggests auto-approve state is **in-memory only** and resets whenever `aac listen` restarts

**TUI keyboard shortcuts for larger increments — tried and failed:**
- `Shift + ↑` — no effect (still 10-min per press)
- `Page Up` / `Page Down` — no effect
- `Alt + ↑` / `Ctrl + ↑` — no effect
- Typing digits directly — no effect

TUI only advances by ~10-minute increments per keypress. To reach even 1 day (1440 min) would require ~144 keypresses.

## Why this matters for daemon-substrate use

Our use case is `aac listen --reusable-psk` running as a background daemon via macOS LaunchAgent, serving credential requests to multiple daemons (Rhino / Council Hermes / etc.) that need periodic re-fetch.

- Auto-approve **resets on every `aac listen` restart** (LaunchAgent respawn, daily maintenance restart, host reboot)
- **Need a way to set a long default duration** (days / weeks) OR make it persist across restarts

## Advice sought

1. **Is there a hidden CLI flag / env var / config file I missed?** Would love a pointer if this is already possible.
2. **TUI keybinding to jump in larger increments** — is there a Shift/Alt/Ctrl modifier or a way to type a value directly?
3. **Design intent:** is auto-approve intentionally in-memory + TUI-only? Or is persistent / config-file-driven auto-approve on the roadmap?

If (1) and (2) both no, would be great to see:
- **`--default-auto-approve-duration `** flag on `aac listen`
- **Persist auto-approve state to disk** (add `auto_approve_until` timestamp field to connection cache entries) so listener restarts don't wipe the window
- **Composes with #147** — headless mode + persistent auto-approve = daemon-substrate becomes first-class

Happy to file a separate feature request if that's the right process. Sharing here first because I'd rather learn I missed something obvious.

## Environment

```
$ aac --version
aac 0.11.0 (3b000d15af71be5ddcf8893b099f3a66d386be9d)
```

macOS 15.5 (Apple Silicon), macOS LaunchAgent Background context.

Related: #147 (headless mode).

Start with `aac listen --help` and the `--reusable-psk` path, then inspect the `connection_cache_user_client.json` entries described in the report. Establish whether auto-approve duration has a supported non-TUI configuration or persistence path; if not, define the requested configuration behavior and restart semantics.

Written by the indexing model from the issue text.