Implement AMIE admin write endpoints (retry / resolve / link)

## Problem

The AMIE connector registers admin write routes and the portal already calls them, but the handlers still return `501 not_implemented`:

- `POST /connectors/amie/packets/{id}/retry`
- `POST /connectors/amie/packets/{id}/resolve`
- `POST /connectors/amie/replies/{id}/retry`
- `POST /connectors/amie/unmapped/{id}/link`

Related read stubs also return empty pages today:

- `GET /connectors/amie/replies`
- `GET /connectors/amie/unmapped`

So operators can see packets in the portal, but cannot manually retry failed work, mark packets resolved, or link unmapped packets.

Parent context: #466

## Expected contract (from portal + MSW mocks)

The web client in `web/src/features/connectors/amie/` already encodes the intended API:

| Endpoint | Body | Success response |
|---|---|---|
| `POST .../packets/{id}/retry` | none | `{ queued: true, packet }` — requeue for processing |
| `POST .../packets/{id}/resolve` | `{ reason }` (3–500 chars) | updated `packet` with status `PROCESSED` |
| `POST .../replies/{id}/retry` | none | `{ queued: true }` |
| `POST .../unmapped/{id}/link` | `{ entity_type, entity_id }` | updated `packet` with `linked_entity`, status `PROCESSED` |

Privileges already exist: `amie:packets:write`, `amie:replies:write`, `amie:unmapped:write`.

## Current backend gaps

1. **Packet retry / resolve** — `amie_packets` + `amie_processing_events` exist and the worker already understands `RETRY_SCHEDULED` / `PERMANENTLY_FAILED`. Manual retry can reset a failed event (`next_retry_at = NULL`, status back to retryable) and bump packet retries. Manual resolve can mark a failed packet `PROCESSED` with an audit/reason.
2. **Reply retry** — replies are sent via `amieclient.ReplyToPacket` but are **not persisted** in a local `amie_replies` table, so list/retry cannot work until reply persistence lands.
3. **Unmapped link** — `amie_packets` has no `linked_entity` columns; unmapped listing is defined in the portal as `DECODED && !linked_entity`. Needs schema + store support.

## Proposed phased delivery

### Phase 1 — Packet retry + resolve (smallest useful slice)
- Implement `POST /packets/{id}/retry` for `FAILED` / permanently-failed packets: reset latest processing event for pickup by the worker; return `{ queued: true, packet }`.
- Implement `POST /packets/{id}/resolve` with `{ reason }`: mark packet `PROCESSED`, record reason (audit and/or `last_error`/event message), stop further automatic retries.
- Unit tests on the server handlers; extend integration coverage where practical.

### Phase 2 — Reply persistence + retry
- Persist outbound replies (new migration + store).
- Implement `GET /replies` and `POST /replies/{id}/retry`.

### Phase 3 — Unmapped list + link
- Add linked-entity fields on packets (migration).
- Implement `GET /unmapped` and `POST /unmapped/{id}/link`.

## Ask for maintainers

Is this phasing OK? Any preference on resolve semantics (mark `PROCESSED` only vs also send an AMIE protocol reply)? Happy to start with Phase 1 if this looks right.

Start with the AMIE client in web/src/features/connectors/amie/ and its MSW mocks to confirm the endpoint contracts, then inspect the existing packet handlers, amie_packets, amie_processing_events, and the worker states named in the issue. Phase 1 is done when packet retry and resolve work with validation, audit or reason recording, and server handler tests; reply persistence and unmapped linking require later migrations and store work.

Written by the indexing model from the issue text.