The Goal chip reads "running" while an armed Goal waits for its first Turn

## What happened

Since #3199 a user can arm a Goal from the ＋ menu. Arming deliberately starts nothing — the Goal waits for a Turn to take hold of it — but the Session context chip renders it exactly like a Goal that is driving itself: `StatusDot` gets `goalRunningAriaLabel` ("Autonomous goal running") and `isPulsing`, because the only states it distinguishes are `paused` and `waiting` (`packages/ui/src/session-context-layer.tsx:136-146`).

So between arming and the user's next Turn the chip pulses and says the Goal is running, while nothing runs and nothing will until the user sends a message.

## How to reproduce

1. Open a Session with no Goal.
2. ＋ menu → 设定 Goal…, enter a condition, 开始.
3. Do not send a message.

The Goal chip shows a pulsing dot labelled "Autonomous goal running". No Turn is admitted.

## Expected

The chip should say the Goal is set and takes hold on the next Turn, and should not pulse as if work were in flight.

## Why the UI cannot tell today

`GoalProjection` (`packages/runtime-host/src/protocol/goal.ts:33`) carries `status` and `iterations`, and neither answers the question. `status: 'active'` covers both an armed Goal waiting for its first Turn and a Goal between continuations. `iterations: 0` covers both an armed Goal and a model-set Goal whose first Turn has not settled yet — and the latter is genuinely driving.

The Host does know. `armedAt` on `GoalState` is present exactly while a Goal is waiting to be driven, and `isDrivingGoal` in `packages/core/src/goal.ts` reads it. It is not on the wire.

## Scope

One field on `GoalProjection` plus a copy string; the Host-side fact already exists. An optional field an older client ignores should not need a compatibility epoch, but that is worth confirming when the change is made.

## Environment

- Maka commit: 57e08d834 (`main`)
- Surface: Desktop

*(Filed with Claude Code (Opus 5); the cited lines were read from `main` at 57e08d834.)*