svm_word_predictor._validate_tokenization raises ValueError on hyphen tokens — ~37k prod failures/30d

## Summary

In production, `SVMWordPredictor._validate_tokenization` is the single largest source of `mmda` failures. The TIMO service `word-predictor-v1` (which wraps `mmda`'s `svm_word_predictor`) failed **~37,150 of ~68,800 invocations (≈54%) over the last 30 days**, every one of them with:

```
ValueError: Document contains Token with hyphen, but not as its own token.
```

This is a hard `raise` in a validation guard, so any document whose tokenization contains a hyphen that isn't isolated as its own token fails the whole prediction.

## Evidence (production, last 30 days)

Representative traceback (deployed `mmda`, `word-predictor-v1` SageMaker container):

```
File ".../mmda/predictors/sklearn_predictors/svm_word_predictor.py", line 233, in predict
self._validate_tokenization(document=document)
File ".../mmda/predictors/sklearn_predictors/svm_word_predictor.py", line 350, in _validate_tokenization
raise ValueError(
ValueError: Document contains Token with hyphen, but not as its own token.
```

| service | model_package | failures (30d) | share of service invocations |
|---|---|---:|---:|
| word-predictor-v1 | mmda | ~37,150 | ~54% |

Source: `timo_services.invocations` Athena table, window 2026-05-10 → 2026-06-09.

### How to regather (Athena CLI)

```bash
aws athena start-query-execution \
--query-execution-context Database=timo_services \
--result-configuration OutputLocation=s3:/// \
--query-string "
SELECT regexp_extract(regexp_replace(error,'\s+$',''),'[^\n]*$') AS last_line,
COUNT(*) AS failures
FROM timo_services.invocations
WHERE service='word-predictor-v1' AND outcome='failure'
AND year=2026 AND month IN (5,6)
AND timestamp >= to_unixtime(current_timestamp - interval '30' day)
GROUP BY 1 ORDER BY failures DESC"
# then: aws athena get-query-results --query-execution-id --output table
```

Pull offending input PDFs to repro (`metadata` holds `{"pdfSha": ...}`):

```sql
SELECT metadata, error FROM timo_services.invocations
WHERE service='word-predictor-v1' AND outcome='failure'
AND error LIKE '%Token with hyphen%'
AND year=2026 AND month IN (5,6) LIMIT 20
```

## Suggested fix

A hard `raise` here turns a recoverable tokenization quirk into a total prediction loss for ~half of all traffic. The validation guard should either **repair** the input or **degrade gracefully**, not abort. Two options:

**Option A — downgrade the guard to a warning and skip the offending document path** (smallest change, immediately cuts the failure rate to ~0):

```python
# svm_word_predictor.py — _validate_tokenization
import logging
logger = logging.getLogger(__name__)

def _validate_tokenization(self, document: Document) -> None:
...
if :
logger.warning(
"Document contains Token with hyphen, but not as its own token; "
"skipping hyphen-aware word merging for affected tokens."
)
return # instead of raise ValueError(...)
```

**Option B — normalize the tokenization before validation** (preferred long-term): split any token of the form `foo-bar` so the hyphen is its own token, which is the exact invariant the validator demands:

```python
def _normalize_hyphen_tokens(self, document: Document) -> None:
"""Ensure every '-' is its own token before word prediction."""
# re-tokenize tokens matching r'\S+-\S+' into [left, '-', right]
...

def predict(self, document: Document) -> List[SpanGroup]:
self._normalize_hyphen_tokens(document)
self._validate_tokenization(document=document)
...
```

If the upstream parser (`pdfplumber_parser`) is expected to guarantee isolated-hyphen tokens, then this is a parser/predictor contract mismatch and the fix belongs there instead — but the guard should still degrade rather than `raise`.

---
*Filed from production failure analysis of the TIMO `invocations` table. Related: #206 (older catch-all failure log), #250 (page-index `IndexError` family).*