Send client identification headers (client, version, skill) from all HTTP clients

## Problem

The HTTP clients in this repo send no client identification, so requests that reach the hosted backends carry nothing that says *which skill*, *which client*, or *which CLI version* made them. Every hosted skill routes through `${auth.gateway_url}/api/` (`src/asta/utils/asta.conf`), but the clients set only two headers:

```python
self.headers = {
"Content-Type": "application/json",
"Authorization": f"Bearer {self.access_token}",
}
```

(`src/asta/papers/client.py`, `src/asta/literature/client.py`, and the same shape in the other clients.)

Consequences for anyone looking at server-side telemetry:

- `paper-finder` serves both `find-literature` and `literature-report`, so per-skill usage is unrecoverable — the backend name is the finest available grain.
- There is no way to tell which CLI release a request came from, so upgrade/adoption rate after a release is unanswerable.
- Requests fall back to library-default user agents (`Python-urllib/3.x`, `python-httpx/…`), which identify the HTTP library rather than this project.

## Proposal

One shared header builder used by every client, sending:

| Header | Value | Source |
|---|---|---|
| `User-Agent` | `asta-cli/` | package version |
| `X-Asta-Client` | `cli` (or `mcp`, `a2a`) | call path |
| `X-Asta-Client-Version` | `` | package version |
| `X-Asta-Skill` | invoking skill name, e.g. `find-literature` | threaded from the invoking command |

The version already exists in `pyproject.toml` and is kept in sync by `plugins/asta-tools/hooks/sync-cli-version.sh`, so no new source of truth is needed. The skill name is the only value that has to be threaded through from the caller; where it is unavailable, omitting the header is better than guessing.

No request content or user data is added — these are client-identification headers only.

## Notes

- This is deliberately client-side only. The receiving side needs a matching change to record the headers; that is tracked separately by the service owners.
- Rolling this out takes a release plus user upgrades, so it is the slower half of the work — worth starting early for that reason.

Suggested-by: @jbragg