Implement admin-driven automatic namespace bans

## Background

CompliK currently has the detection and reporting pieces needed for automatic enforcement, but the actual ban workflow is split and incomplete:

- `complik` reports content violations to admin through `/api/complik-violations`.
- `procscan` reports runtime process violations to admin through `/api/procscan-violations`.
- `sealos-complik-admin` stores violation events and has `ban` / `unban` records plus namespace ban status APIs.
- `procscan` has namespace-label action code, but the deployed config keeps it disabled. That action should move to admin so enforcement decisions are centralized.
- The repository docs describe a Block Controller-style handoff where a namespace label triggers the actual namespace blocking behavior.

## Goal

Implement automatic namespace banning as an admin-driven workflow:

```text
complik / procscan detects a violation
-> reports the violation to sealos-complik-admin
-> admin stores the violation event
-> admin autoban policy decides whether to ban
-> admin creates a ban record for audit/UI
-> admin labels the namespace
-> Block Controller performs the actual cluster enforcement
```

This keeps detection, decision/audit, and cluster enforcement separated:

- `complik` and `procscan`: detection and reporting only.
- `sealos-complik-admin`: autoban policy, dedupe, audit record, namespace label handoff.
- Block Controller: actual Kubernetes resource enforcement.

## Proposed Implementation

### 1. Add an admin-side `autoban` module

Add a new internal module under:

```text
sealos-complik-admin/internal/modules/autoban/
```

Suggested files:

```text
service.go # public HandleComplikViolation / HandleProcscanViolation entry points
policy.go # enablement, source-specific policy, namespace/process-name allow/deny handling
executor.go # namespace label patch execution
model.go # optional autoban job/action records for retry/audit
dto.go # optional policy/config response structs
```

The service should:

- ignore non-illegal events;
- ignore CompliK test events;
- validate namespace;
- skip namespaces that are already banned;
- create a ban record with `operator_name = "system/autoban"`;
- patch the namespace with the agreed block label;
- record enough reason metadata to make the ban auditable.

### 2. Trigger autoban after violation persistence

Call the autoban service after successful violation insertions:

- `sealos-complik-admin/internal/modules/complikviolation/services.go` after `CreateViolation` succeeds.
- `sealos-complik-admin/internal/modules/procscanviolation/services.go` after `CreateViolation` succeeds.

Autoban should not prevent violation ingestion when enforcement fails. Prefer logging and/or job status for enforcement failures.

### 3. Move namespace labeling responsibility to admin

Admin should be the component that patches namespace labels. `procscan` should continue to report violations and send alerts, but its namespace label action should remain disabled or be deprecated as the primary enforcement path.

The finalized label contract is:

```yaml
block.sealos.io/locked: "true"
```

### 4. Add Block Controller enforcement

Add or restore a Block Controller that watches namespaces for the agreed label and performs actual enforcement, for example:

- apply network isolation;
- apply zero pod/service resource quotas;
- keep status/events for observability;
- support unban by reacting to label removal.

The controller should be the only component that performs destructive or resource-mutating enforcement beyond namespace labels.

### 5. Update admin deployment RBAC

Because admin will patch namespace labels, its ServiceAccount needs at least:

```yaml
resources: ["namespaces"]
verbs: ["get", "list", "watch", "patch", "update"]
```

The Block Controller will need separate RBAC for the actual enforcement actions it owns.

## Configuration

Add an admin-managed autoban policy through the existing project config mechanism, `autoban_policy`:

```json
{
"enabled": true,
"dryRun": false,
"operatorName": "system/autoban",
"sources": {
"complik": { "enabled": true },
"procscan": { "enabled": true }
},
"processNameAllowlist": ["xmrig", "minerd"],
"processNameDenylist": ["systemd"],
"namespaceDenylist": ["kube-system", "sealos", "block-system"]
}
```

Start with conservative defaults: disabled and dry-run by default unless deployment explicitly enables it.

## Acceptance Criteria

- A CompliK illegal violation can trigger an admin-created ban record and namespace block label.
- A Procscan illegal violation can trigger an admin-created ban record and namespace block label.
- Non-illegal and test events do not trigger autoban.
- Repeated violations for an already banned namespace do not create duplicate active ban actions.
- If namespace label patching fails, the violation event remains stored and the ban record does not remain active without enforcement.
- Admin deployment includes the namespace patch RBAC it needs.
- Block Controller reacts to `block.sealos.io/locked=true` and performs the real namespace enforcement.
- Tests cover policy decisions, duplicate-ban avoidance, and executor failure handling.

## Open Questions

- Should autoban execute synchronously after violation insertion, or use an async job/outbox table for retry and failure status?
- What exact enforcement should Block Controller perform for later releases beyond network isolation and zero pod/service quota?
- Should unban remove the block label automatically, or should unban remain manual until controller recovery behavior is defined?

Start with the violation insertion points in sealos-complik-admin/internal/modules/complikviolation/services.go and internal/modules/procscanviolation/services.go, then review the proposed internal/modules/autoban/ entry points and existing project config mechanism. Check the deployment RBAC and repository Block Controller documentation. Done means policy and duplicate handling are tested, violations remain stored on enforcement failure, the namespace label and RBAC work, and the controller enforces and reverses the ban.

Written by the indexing model from the issue text.