Proposal: compatibility diagnostics, sanitized support bundles, and API replay tests

### Current version

0.6.4

### Describe the feature

## Proposed direction

Xiaohongshu's private web APIs and response schemas can change without notice. I propose a small compatibility and diagnostics layer that makes failures reproducible without exposing user credentials.

### Phase 1: `xhs doctor`

Add a machine-readable diagnostic command:

```bash
xhs doctor --json
```

It would report:

- CLI and Python versions
- authentication availability
- individual capability status
- active endpoint
- HTTP/API error category
- whether verification is required

It must never output cookies, session values, signing headers, or private account data.

### Phase 2: sanitized support bundle

Add:

```bash
xhs support-bundle -o xhs-support.json
```

The bundle would contain only sanitized diagnostics suitable for attaching to a GitHub issue. Sensitive fields would be removed by an allowlist, rather than relying only on key-name masking.

### Phase 3: response-contract fixtures

Introduce sanitized API response fixtures and offline replay tests so that response schema changes can be detected and fixed without requiring real cookies in CI.

Possible initial coverage:

- search
- note detail
- comments
- login status
- current user

## Implementation approach

I propose implementing this as several small PRs:

1. capability model and `xhs doctor`
2. sanitization utility and `support-bundle`
3. sanitized fixtures and replay tests

Each PR would remain independently useful and reviewable.

### Use case

## Motivation

When a command fails today, users often can only report “it stopped working”. Maintainers then need to determine whether the problem comes from:

- expired cookies
- request signing changes
- endpoint changes
- response schema changes
- captcha or account risk control
- IP/network restrictions

The proposed diagnostics would help users provide actionable, privacy-safe reports and let maintainers reproduce response-contract regressions offline.

## Non-goals

This proposal would not initially add:

- a daemon
- telemetry
- automatic upload of diagnostics
- a new networking abstraction
- automatic API reverse engineering
- write-operation automation
- real user credentials in tests

## Questions

1. Would this direction be useful to the project?
2. Is `xhs doctor` an acceptable command name?
3. Which 3–5 commands should be included in the first capability probe?
4. Would you prefer fixtures committed under `tests/fixtures/`?
5. Should this proposal stay CLI-only initially, with MCP considered separately?

If the direction is accepted, I can start with Phase 1 as a small PR.

Start by resolving the proposal's open questions about xhs doctor, capability coverage, fixture location, and CLI-only scope. Define Phase 1 separately from the support-bundle and response-contract fixture phases; completion should include an agreed command scope, sanitized diagnostic behavior, and independently reviewable tests or fixtures under tests/fixtures/.

Written by the indexing model from the issue text.