validate_api_access() hardcodes retired claude-3-5-haiku-20241022 — silently disables FP filtering since 2026-02-19

### Summary

`validate_api_access()` in `claudecode/claude_api_client.py` hardcodes a retired model for its health check:

```python
# claudecode/claude_api_client.py:62
self.client.messages.create(
model="claude-3-5-haiku-20241022",
...
)
```

`claude-3-5-haiku-20241022` was retired on 2026-02-19, so this call now fails unconditionally with a 404 (`not_found_error`) — regardless of what the user passes as the `claude-model` action input, which never reaches this call.

### Impact: FP filtering silently disabled, runs stay green

When the health check fails, `FindingsFilter.__init__` (`claudecode/findings_filter.py`) logs a warning and sets `use_claude_filtering = False`. The action then completes successfully — so every run since the retirement has been executing **without Claude-powered false-positive filtering**, with no failure signal to the workflow. The only symptoms are a warning buried in the logs, noisier findings, and failed-request entries on the API key (which is how we noticed: Anthropic's retirement notice flagged our key for repeated failed requests to the retired model).

### Fix

Use `self.model` — the model the client was constructed with and will actually use for filtering calls — so the health check validates the same access it guards:

```python
model=self.model,
```

PR incoming with this one-line change.

### Related

`DEFAULT_CLAUDE_MODEL` in `claudecode/constants.py` falls back to `claude-opus-4-1-20250805`, which is also retired — users who don't set `claude-model`/`CLAUDE_MODEL` will still hit failures on the real filtering calls even with this fix. Bumping that default to a current model (e.g. `claude-haiku-4-5-20251001` or a current Sonnet) may be worth doing in the same pass.