[e2e-scan] Test: Improve e2e coverage for organization external team membership with system accounts and users (new scenario)

### Gap Summary

The `_external` selector pattern for referencing teams created outside of declarative management is tested for **team roles** in `org/teams/external-role`, but never for **system account team memberships** or **user team memberships**. This leaves the external team resolution path in system account and user assignment validation completely unexercised at the E2E level.

This matters because:
- The external team reference path in `organization_system_account_load.go` and `organization_user_load.go` hits a distinct `tags.IsExternalPlaceholder` branch that skips normal team reference validation — this branch is only unit-tested, never E2E-verified against Konnect.
- External team references are a real-world pattern: teams managed through the Konnect UI or API should be referenceable as assignment targets without requiring full declarative management.
- The planner and executor must correctly resolve external team selectors by name match, produce a valid plan, and execute against Konnect — all of which have separate failure modes from inline team refs.

### Evidence

- **Tested analogue**: `test/e2e/scenarios/org/teams/external-role/` exercises the `_external` pattern for `organization_team_role` with `testdata/config.yaml` showing the `_external.selector.matchFields.name` pattern.
- **Untested validation branches**:
- `internal/declarative/resources/organization_system_account_load.go:60` — `if tags.IsExternalPlaceholder(membership.Team) { continue }`
- `internal/declarative/resources/organization_user_load.go:60` — `if tags.IsExternalPlaceholder(membership.Team) { continue }`
- **No existing E2E scenario** under `test/e2e/scenarios/org/system-accounts/` or `test/e2e/scenarios/org/users/` uses the `_external` tag on a team reference.

### Proposed Scenario Work

Create a new scenario at `test/e2e/scenarios/org/system-accounts/external-team/` (and optionally a parallel `test/e2e/scenarios/org/users/external-team/`). The nearest existing scenarios (`org/system-accounts/assignments`, `org/users/assignments`) are not a good fit because they are already complex (5+ steps with portal entity ref), environment-pinned, and focused on assignments with declaratively managed teams. The external team bootstrap pattern requires a harness `create` step for an unmanaged team, which would broaden those scenarios' purpose.

**Outline for system account external team scenario:**

1. **Reset org** — `resetOrg: true`
2. **Bootstrap external team** — `create: resource: organization_team` (no `KONGCTL-namespace` label), record `team_id`
3. **Create system account** — `create: resource: system-account`, record `system_account_id`
4. **Apply config with external team membership** — config YAML uses `_external.selector.matchFields.name` on the team ref, declares `organization_system_account_team_membership` referencing the external team
- Assert plan shows CREATE for the team membership
- Assert apply succeeds with `failed: 0`
5. **Verify assignment** — `get org system-account teams --system-account-name` and assert the external team appears
6. **Diff idempotency** — `diff` shows `total_changes: 0`
7. **Sync remove assignment** — remove the membership from config, sync should DELETE the membership but leave the external team intact
8. **Verify external team still exists** — `get org teams` and assert the team is still present

**Config template (testdata/config.yaml):**
```yaml
organization:
teams:
- ref: external-team
name:
_external:
selector:
matchFields:
name:

system-accounts:
- ref:
name:
teams:
- ref:
team: external-team
```

### Acceptance Criteria

- [ ] New scenario creates a team via harness API without `KONGCTL-namespace` label
- [ ] Config references the external team using `_external.selector.matchFields.name`
- [ ] Apply correctly resolves the external team and creates the system account team membership
- [ ] Diff returns zero changes after apply (idempotency)
- [ ] Sync removal deletes the membership but leaves the external team intact
- [ ] Get command verifies the team membership exists after apply and is gone after sync
- [ ] Optionally, a parallel `org/users/external-team/` scenario tests the same pattern for user team memberships

### Reference Patterns

- `test/e2e/scenarios/org/teams/external-role/` — demonstrates the `_external` selector pattern for team roles, including bootstrap, plan, apply, idempotency, sync delete, and post-delete team existence check
- `test/e2e/scenarios/org/system-accounts/assignments/scenario.yaml` — demonstrates system account team membership with declaratively managed teams
- `test/e2e/scenarios/org/system-accounts/sync/scenario.yaml` — demonstrates sync workflow for system account assignments

> Generated by [E2E Coverage Scanner](https://github.com/Kong/kongctl/actions/runs/35056794017) · opus46 · 320.6 AIC · ⌖ 30.7 AIC · ⊞ 6.7K · [◷](https://github.com/search?q=repo%3AKong%2Fkongctl+is%3Aissue+%22gh-aw-workflow-call-id%3A+Kong%2Fkongctl%2Fe2e-coverage-scanner%22&type=issues)
> - [x] expires on Oct 16, 2026, 4:58 AM UTC

Start with test/e2e/scenarios/org/teams/external-role/ and its testdata/config.yaml, then compare the system-account patterns in org/system-accounts/assignments/scenario.yaml and sync/scenario.yaml. Build the new scenario under org/system-accounts/external-team/, covering bootstrap, external-team membership apply, idempotent diff, sync removal, and verification that the external team remains.

Written by the indexing model from the issue text.