fix(format): include pure renames from GitHub PR Files API (#1160)

A renamed file with no content change comes back from GitHub's PR Files
API as `status: "renamed"` with `+0/-0`. The legacy CLI and the new
CLI's PR Files API fallback path were bucketing those entries as
diagnostic-only, so `aspect format` silently omitted the renamed
destination from the formatter's arg list.

The fix is a `line_level`-conditional rule:

- **Format (`line_level=False`)**: pure renames flow into the actionable
file list — the formatter needs to run on the destination. Matches the
local `git diff --name-only` path that already includes them.
- **Lint (`line_level=True`)**: pure renames remain skipped — the local
`git diff --unified=0` path emits no `+++ b/...` for a 100%-rename, and
surfacing the file would regress `--strategy=hold-the-file` by exposing
pre-existing findings unrelated to the PR.

Logic is factored into `_pr_file_is_skipped(status, additions,
deletions, line_level)` with a unit test covering every `(status, +N/-N,
line_level)` combination.

### Changes are visible to end-users: yes

- Searched for relevant documentation and updated as needed: no
- Breaking change (forces users to change their own code or config): no
- Suggested release notes appear below: yes

**Suggested release notes:**

- `aspect format` now includes pure renames (files moved without content
changes) reported by the GitHub PR Files API fallback path. Previously
these were silently dropped from the formatter's file list.

### Test plan

- 12 new unit-test cases in `test-github-detect` covering the bucketing
predicate across every `(status, additions, deletions, line_level)`
combination.
- `test-format-template-snapshots` and `test-lint-template-snapshots`
confirm no regression on the rendered surfaces.

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>