chore: rename cameleer3 to cameleer

Rename Java packages from net.siegeln.cameleer3 to net.siegeln.cameleer,
update all references in workflows, Docker configs, docs, and bootstrap.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/superpowers/specs/2026-04-07-architecture-review.md

@@ -2,7 +2,7 @@
 
 **Date:** 2026-04-07
 **Status:** Ready for review
-**Scope:** cameleer3 (agent), cameleer3-server, cameleer-saas
+**Scope:** cameleer (agent), cameleer-server, cameleer-saas
 **Focus:** Responsibility boundaries, architectural fitness, simplification opportunities
 **Not in scope:** Security hardening, code quality, performance
 
@@ -12,9 +12,9 @@
 
 The cameleer ecosystem has a clear vision: a standalone observability and runtime platform for Apache Camel, optionally managed by a thin SaaS vendor layer. Both deployment modes must be first-class.
 
-The agent (cameleer3) is architecturally clean. Single job, well-defined protocol.
+The agent (cameleer) is architecturally clean. Single job, well-defined protocol.
 
-The server (cameleer3-server) is solid for observability but currently lacks runtime management capabilities (deploying and managing Camel application containers). These capabilities exist in the SaaS layer today but belong in the server, since standalone customers also need them.
+The server (cameleer-server) is solid for observability but currently lacks runtime management capabilities (deploying and managing Camel application containers). These capabilities exist in the SaaS layer today but belong in the server, since standalone customers also need them.
 
 The SaaS layer (cameleer-saas) has taken on too many responsibilities: environment management, app lifecycle, container orchestration, direct ClickHouse access, and partial auth duplication. It should be a thin vendor management plane: onboard tenants, provision server instances, manage billing. Nothing more.
 
@@ -29,17 +29,17 @@ The SaaS layer (cameleer-saas) has taken on too many responsibilities: environme
 
 ## What's Working Well
 
-### Agent (cameleer3)
-- Clean separation: core logic in `cameleer3-core`, protocol models in `cameleer3-common`, delivery mechanisms (agent/extension) as thin wrappers
+### Agent (cameleer)
+- Clean separation: core logic in `cameleer-core`, protocol models in `cameleer-common`, delivery mechanisms (agent/extension) as thin wrappers
 - Well-defined agent-server protocol (PROTOCOL.md) with versioning
 - Dual-mode design (Java agent + Quarkus extension) is elegant
 - Compatibility matrix across 40 Camel versions demonstrates maturity
 - No changes needed
 
-### Server (cameleer3-server)
+### Server (cameleer-server)
 - Two-database pattern (PostgreSQL control plane, ClickHouse observability data) is correct
 - In-memory agent registry with heartbeat-based auto-recovery is operationally sound
-- `cameleer3-server-core` / `cameleer3-server-app` split keeps domain logic framework-free
+- `cameleer-server-core` / `cameleer-server-app` split keeps domain logic framework-free
 - SSE command push with Ed25519 signing is well-designed
 - The UI is competitive-grade (per UX audit #100)
 - Independent user/group/role management works for standalone deployments
@@ -392,7 +392,7 @@ Step 8 is the SaaS cleanup after server capabilities are in place.
 - **saas#37 (admin tenant creation UI):** SaaS UI becomes vendor-focused, simpler
 
 ### Issues that become more important:
-- **agent#33 (version cameleer3-common independently):** Critical before server API contract stabilizes
+- **agent#33 (version cameleer-common independently):** Critical before server API contract stabilizes
 - **server#46 (OIDC PKCE for SPA):** Required for server-ui in oidc-only mode
 - **server#101 (onboarding experience):** Server UI needs guided setup for standalone users