agent-approval-check ignores valid approvers before repository permission check

## Summary

`agent-approval-check` reports `0/N` approvals even when reviewers have approved the current head commit and have repository write access. The same problem affects a valid `/approve ` comment.

The action completes successfully and posts a new pending commit status, but it never calls the collaborator-permission endpoint for any candidate. This suggests candidates are being discarded by the `authorAssociation` pre-filter before the authoritative permission check runs.

## Environment

- Action: `anthropics/claude-code-action/agent-approval-check`
- Revision: `d40ddef4c030e508327d6e35a9c45f3368482c50` (`v1.0.195`)
- Private organization repository
- Events reproduced with: `pull_request_target` and `issue_comment`
- Effective `GITHUB_TOKEN` permissions:

```text
Contents: read
PullRequests: write
Statuses: write
```

## Steps to reproduce

1. Open a PR containing a commit whose committer email matches `agent_emails`.
2. Have multiple users with repository write access submit `APPROVED` reviews on the current head commit.
3. Trigger reevaluation with `ready_for_review`, `synchronize`, or a valid `/approve ` comment.
4. Inspect the action log and resulting `agent-approval-check` commit status.

## Actual behavior

The action detects the agent commit but counts no approvers:

```text
Agent commit detected:
Agent activity detected. Head SHA:
Total approvers: 0 ()
Set status: pending — Need 2 approvals (have 0)
```

There are no `Permission check:` log entries. A subsequent valid `/approve ` comment triggers an `issue_comment` run, but that run produces the same result and does not log `Counting /approve`.

Outside the workflow, querying the same PR shows that all reviews are:

- `APPROVED`
- associated with the current head SHA
- authored by users with `write` repository permission

## Expected behavior

Approved reviews and `/approve` comments from users with verified `write`, `maintain`, or `admin` repository permission should count, even when `authorAssociation` cannot identify their organization membership.

## Suspected cause

Both `count_approvers()` and `iter_approve_commands()` apply this pre-filter before calling the collaborator-permission endpoint:

```python
if item.get("author_association") not in WRITE_ACCESS_ASSOCIATIONS:
continue
```

The original implementation discussion describes this as a cheap pre-filter. In a private organization, however, a repository-scoped `GITHUB_TOKEN` may not be able to see private organization membership reliably. A valid approver can therefore be discarded before `has_write_permission()` is called.

## Suggested fix

Use the existing collaborator-permission endpoint as the authoritative test instead of requiring `authorAssociation` first:

```python
if not permission_check(login):
continue
```

Removing the pre-filter should not weaken the security model because the permission endpoint already requires `write`, `maintain`, or `admin`. Alternatively, fall back to the permission endpoint whenever `authorAssociation` is missing or outside the expected set.

It would also help to log each review/comment candidate's state and association before filtering, so future false negatives can be diagnosed from workflow logs.

## Related context

- #1663 tracks the lack of tests and CI coverage for this component.
- The original implementation discussion retained `authorAssociation` as a cheap pre-filter: https://github.com/anthropics/claude-code-action/pull/1429#discussion_r3459306739