feat: unified configuration schema with hierarchical global defaults

## Problem

Settings are fragmented across too many layers: host-side `.env` files, git-committed `config/settings.yaml`, container-level `hub.env` variables, and stateful database rows in `hub.db`. This creates several pain points:

- **The DB Trap:** Configuring a "global" service account key across all projects originally requires direct SQL database manipulation (`hub.db`) because there is no clean file-based config or CLI flag to set it globally.
- **Redundancy:** Credentials and GCP settings must be defined repeatedly on a per-project basis, violating DRY principles.
- **Fragility:** Settings can be silently overwritten on deploy (see #475), lost on restart (see #147), or ignored when defaults aren't respected (see #212).

This affects **all deployment targets** (GCE, Kubernetes, workstation, NAS) — not just any particular environment.

## Proposal

### (a) Unified Configuration Schema

Consolidate all configuration into a single, comprehensive schema-validated YAML file (e.g., `settings.yaml`). Provide a fully documented master template (`settings.yaml.example`) detailing every key (global credentials, API keys, network settings, telemetry configurations) so users never have to guess or search design docs.

### (b) Hierarchical Global Defaults

Introduce a `global_defaults` block in the unified settings configuration:

```yaml
server:
global_defaults:
auth:
selected_type: vertex-ai
service_account_key_path: /secrets/credentials/credentials.json
gcp:
project_id: my-project
region: us-east5
```

Any project or agent provisioned without explicit auth values should automatically inherit these defaults, eliminating redundant setup.

## Related Issues

- #475 — `gce-start-hub.sh --full` overwrites `settings.yaml`
- #147 — Admin settings lost on pod restart in Kubernetes
- #212 — `default_harness_config` not respected after init
- #473 — Read/write project config as agent-accessible tool

Start by reviewing the existing config/settings.yaml, host .env files, hub.env variables, and hub.db handling, along with related issues #475, #147, and #212. Define the schema and documented settings.yaml.example, then trace how project and agent provisioning reads defaults. Done means configuration is schema-validated, global_defaults are inherited when values are absent, and the behavior works across the listed deployment targets.

Written by the indexing model from the issue text.