daily_paper `write_atomic` crashes on PDF with surrogate characters (U+D800–U+DFFF)

## Bug Description

`daily_paper` job crashes when analyzing a paper whose PDF text contains surrogate characters (U+D800–U+DFFF). The crash happens in `write_atomic` -> `content.encode("utf-8")` raises `UnicodeEncodeError: surrogates not allowed`.

The entire job exits with error, and any remaining papers in the daily selection are never processed.

## Environment

- QwenPaw: 2.1.0
- ReMe: 0.4.1.5 (bundled)
- Python: 3.12
- OS: Windows 10

## Root Cause

1. Some PDFs contain text that pypdf extracts as surrogate characters (invalid Unicode)
2. The LLM receives the PDF text in its prompt and may return surrogate characters in its response
3. `write_atomic` at `reme/steps/cookbook/daily_paper/_common.py:97` calls `content.encode("utf-8")` without sanitizing surrogate characters
4. Python's UTF-8 encoder rejects surrogates by design (`UnicodeEncodeError: 'utf-8' codec can't encode characters ... surrogates not allowed`)

## Impact

- Entire daily_paper job fails on a single bad paper
- Remaining selected papers are never processed
- No retry mechanism for individual paper failures

## Suggested Fix

In `_common.py`, the `write_atomic` function should sanitize surrogate characters before encoding:

```python
import re

_SANITIZE_SURROGATES = re.compile(r"[\ud800-\udfff]")

async def write_atomic(path: Path, content: str | bytes) -> None:
path.parent.mkdir(parents=True, exist_ok=True)
lock = await get_path_lock(path)
async with lock:
temp_path = path.with_name(f".{path.name}.{uuid4().hex}.tmp")
if isinstance(content, str):
content = _SANITIZE_SURROGATES.sub("", content)
payload = content.encode("utf-8") if isinstance(content, str) else content
# ... rest unchanged
```

Alternatively, the sanitization could be done earlier in the pipeline (e.g., after PDF text extraction or after LLM response), but `write_atomic` is the most defensive place since it's the final encoding step before writing to disk.

Start in reme/steps/cookbook/daily_paper/_common.py at write_atomic and inspect the content encoding path. Reproduce the failure with text containing characters in U+D800–U+DFFF, then verify that writing such content no longer raises UnicodeEncodeError and that normal byte content remains supported.

Escrito por el modelo de indexación a partir del texto del issue.