Adopt cargo-xtask pattern for development workflow tasks and profile builds

## Objective

Introduce a workspace `xtask` crate supporting feature combination profile builds (`minimal`, `postgres`, `mysql`, `sqlite`, `aws`, `vault`, `gcp`, `azure`, `all`) and common development workflow tasks so developers and CI can uniformly compile, test, and validate configurations.

## Context

The project currently uses scripts such as `local-ci.sh` and ad-hoc `cargo` commands with hardcoded flags. Moving to the `cargo-xtask` pattern keeps task definitions in Rust where they are cross-platform, composable, and easy to extend. Furthermore, because the server supports multiple modular backends (PostgreSQL, MySQL, SQLite, in-memory) and multi-cloud KMS/secret store integrations (AWS, Vault, GCP, Azure), developers need an easy way to verify that every feature combination compiles and passes tests without manually typing complex feature sets.

## Feature Profiles Matrix

The `xtask` pattern must support the following profiles:

| Profile Name | Cargo Feature Set | Description |
|---|---|---|
| `minimal` | `--no-default-features` (or `memory`) | Core status list protocol without database or external dependencies |
| `postgres` | `postgres` | Default relational database backend |
| `mysql` | `mysql` | MySQL/MariaDB database backend |
| `sqlite` | `sqlite` | Local file/in-memory SQLite backend |
| `aws` | `postgres,aws` | AWS Secrets Manager and Route53 DNS |
| `vault` | `postgres,vault` | HashiCorp Vault / OpenBao backend |
| `gcp` | `postgres,gcp` | GCP Secret Manager and Cloud DNS |
| `azure` | `postgres,azure` | Azure Key Vault and Azure DNS |
| `all` | `--all-features` | Complete feature set including test gates |

## Deliverables

- [ ] **Workspace setup:**
- Add `xtask` crate in workspace root (`[workspace] members = [".", "xtask"]`).
- Configure `.cargo/config.toml` alias: `xtask = "run --package xtask --"`.
- [ ] **Profile-aware commands:**
- `cargo xtask check-profiles`: iterates over each profile in the matrix and runs `cargo check` to guarantee compile-time feature independence and detect accidental feature leaks.
- `cargo xtask build [--profile ]`: builds the server binary with the selected profile (defaults to `postgres`).
- `cargo xtask test [--profile ]`: runs tests for the selected profile.
- [ ] **Development workflow tasks:**
- `cargo xtask lint`: runs `cargo fmt --check`, `cargo clippy --workspace --all-targets --all-features -- -D warnings`, `cargo audit`, and `cargo machete`.
- `cargo xtask compose [--profile ]`: launches corresponding Docker Compose services.
- `cargo xtask ci`: runs the full local validation pipeline.
- [ ] **Documentation:**
- Document all `cargo xtask` commands in `README.md` and `CONTRIBUTING.md`.

## Acceptance Criteria

- [ ] `cargo xtask check-profiles` verifies all 9 profiles cleanly.
- [ ] `cargo xtask build --profile ` builds the binary with the corresponding features.
- [ ] `cargo xtask lint` runs all formatting, clippy, and security lints.
- [ ] Developers can invoke tasks via standard `cargo xtask `.

## References

- `Cargo.toml`
- PR #232 (`169-adopt-cargo-xtask-pattern-for-development-workflow-tasks-and-profile-builds`)

Start with root `Cargo.toml` and `.cargo/config.toml` to add the `xtask` workspace member and alias. Then inspect `local-ci.sh` and align its existing workflow into `cargo xtask` tasks using the profile matrix for `check-profiles`, `build`, `test`, `lint`, `compose`, and `ci`. Update `README.md` and `CONTRIBUTING.md` with the exact command usage and profile names. Completion is when the new commands are in place, documented, and `cargo xtask check-profiles`, `cargo xtask build --profile `, and `cargo xtask lint` are runnable for the listed profiles.

由索引模型根據 Issue 內容生成。