Expose the client device a turn came from, so a session can hold per-device context

### The gap

A Claude Code session knows a great deal about the machine it **runs on** — working
directory, platform, git branch, host name via the shell. It knows nothing about the
**device the user is typing from**. Those are increasingly different things: the same
session can be reached from a desktop at one location, a laptop at another, or a phone,
and nothing in the conversation distinguishes them.

### Concrete use case

Per-device task separation inside a single conversation. Working across a desktop and a
new laptop, a running to-do list accumulates items that belong to different machines —
"install the IDE" belongs to the laptop, "cancel the cloud-build subscription" belongs
wherever the browser session is, "check the storage unit" belongs to neither. Today they
land in one undifferentiated list and the user has to remember which machine each one
needs. With device context a session could file work against the right device and surface
only what is actionable on the one currently in hand.

This generalises past to-dos: "open this file in the editor" is meaningful on one device
and meaningless on another, and `reveal_path` / `open_in_editor` already act on the
session host regardless of where the user is.

### What is available today — checked, not assumed

- **Session transcript records**: `cwd`, `gitBranch`, `version`, `userType`, `entrypoint`.
`entrypoint` was identical across every record examined, so it does not vary by client.
- **`get_session`**: `cwd`, `model`, `effort`, `isRemote`, timestamps. Nothing client-side.
- **Message `origin`**: distinguishes `{"kind":"human"}` from `{"kind":"peer"}` and
task notifications — i.e. *whether* a human sent it, never from where.
- **Tool surface**: nothing exposes a client device.

The one place a device concept does surface is in tool documentation rather than data.
`delete_session` states that for sessions on a remote host, an approval "in the Claude app
on the user's computer" counts while one "from another device" does not. So the system
distinguishes devices for approval purposes; that distinction is simply not readable from
inside a session.

### What would be enough

Not a full device inventory. Either of these would cover the use case:

1. **A stable per-device identifier on the turn** — opaque is fine, as long as it is
consistent for the same device across reconnects and sessions. An agent can map it to a
human label once and reuse that.
2. **A user-visible device label** (whatever name the device is already registered under),
exposed on the turn or via `get_session`.

The important property is **stability across reconnect**. An identifier that changes each
time cannot anchor anything.

### Why inference is not an acceptable substitute

It is tempting to infer the device from available signals — host name, platform, which
browser extension reports `isLocal`. Every one of those describes the session host or the
account, not where the user is typing, and each can be wrong without saying so.

That matters more than usual here: **a stale device label is worse than no label**. A user
who sees a to-do list filtered for the wrong machine trusts it and acts on it, where an
unfiltered list is merely inconvenient. Any answer that can silently go out of date should
not be built on, which is why this is a request for a first-class signal rather than a
workaround.

### Current fallback

Asking the user which device they are on, once per session, and tagging items manually.
Reliable, and it cannot silently go stale — but it costs a round trip every session and
degrades quietly the moment anyone forgets.

Start by reading the session transcript records, get_session response, message origin handling, and delete_session tool documentation mentioned in the issue. The requested outcome is a stable per-device identifier or user-visible device label available on a turn or through get_session. This likely needs product/API design before implementation, not just a localized code edit.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.