chore(scaffold): initial SilverMetal program scaffold

Cross-platform privacy-hardening program. Two-layer product:
- SilverLABS Application Stack (cross-platform spine)
- Platform Hardening Profiles (per-OS, tier-honest)

Platforms: Linux (Debian/Kicksecure), Android (Pixel/Samsung/Moto/generic),
Windows (LTSC IoT), macOS (profile), iOS (MDM profile). Each flavour has
both a preflashed hardware SKU path and a self-apply "harden your existing
device" path.

Includes umbrella docs (README + threat-model, design-principles,
platform-matrix, roadmap, trust-model), per-platform and per-stack-
component README stubs, .gitignore, LICENSE.

Linux v1 ships first; Stack v1 = Browser + VPN + Sync.

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

docs/trust-model.md

@@ -0,0 +1,101 @@
+# Trust Model
+
+How users (and we) verify what SilverMetal ships. Trust is earned through verifiability, not asserted in marketing.
+
+## What a SilverMetal user trusts
+
+In rough order of decreasing necessity:
+
+1. **The hardware** — at minimum, the CPU and TPM. Coreboot-supported SKUs reduce firmware-level trust requirements. Commodity SKUs do not eliminate them.
+2. **SilverLABS' release signing keys** — to verify a downloaded image is genuine.
+3. **SilverLABS' build process** — to trust the published artefact came from the published source. Reproducible builds let users *verify* this rather than just trust it.
+4. **The platform vendor** — for Windows / macOS / iOS, we cannot eliminate trust in Microsoft / Apple. We say so explicitly.
+5. **SilverLABS' server infrastructure** — for hosted SilverVPN nodes, SilverSync, SilverChat. Self-hosting alternatives are documented.
+6. **Themselves** — to not negate the protections.
+
+## Reproducible builds
+
+Every SilverMetal release artefact is built reproducibly:
+
+- Pinned toolchain versions
+- Pinned dependency hashes
+- Stripped of build-environment metadata (timestamps, paths, host info)
+- CI re-builds from a clean checkout and verifies identical output
+
+The reproducibility procedure is published per-component. Anyone can:
+1. Clone the repo at the release tag
+2. Run the documented build command
+3. Compare SHA256 of their artefact to the published one
+
+Mismatch = supply chain anomaly. Report channel: `security@silverlabs.uk`.
+
+## Signing keys
+
+| Key | Purpose | Storage | Rotation |
+|---|---|---|---|
+| **SilverMetal Release** | Signs ISO/ROM/installer artefacts | Offline (HSM, ceremony-only access) | Major-version |
+| **SilverMetal Update Channel** | Signs OTA / apt updates | Online but isolated; sub-key model | Yearly or on compromise |
+| **SilverMetal Code Signing — Linux** | Signs `.deb`, kernel modules | Offline | Major-version |
+| **SilverMetal Code Signing — Windows** | Authenticode cert for `.exe`/`.msi` | HSM or signing service | Per-cert lifetime |
+| **SilverMetal Code Signing — macOS/iOS** | Apple Developer ID cert | Apple-managed | Per-cert lifetime |
+| **SilverMetal MOK (Linux Secure Boot)** | Our Machine Owner Key for Secure Boot | Offline | Major-version |
+| **SilverMetal AVB (Android verified boot)** | Android verified-boot key | Offline | Per-device-generation |
+
+Key fingerprints are published in `shared/signing/KEYS.md` (to be populated at first key generation).
+
+### Key ceremony policy
+- All offline keys generated in air-gapped environment
+- Multi-party control where feasible (M-of-N for the most critical keys)
+- Rotation procedure documented before keys are first used
+- Compromise procedure documented before keys are first used
+
+## SBOM (Software Bill of Materials)
+
+Every release publishes a complete SBOM in CycloneDX format:
+
+- All packages with version, source, license, hash
+- Build-time vs. runtime dependencies distinguished
+- Reproducible-build attestation linked
+
+SBOMs live in the release-page's `sbom/` directory.
+
+## Vulnerability response
+
+| Severity | Triage | Fix | Disclosure |
+|---|---|---|---|
+| Critical (active exploitation) | < 24h | Out-of-band release | Coordinated, then public |
+| High | < 72h | Next scheduled release | Coordinated, then public |
+| Medium | < 2 weeks | Next scheduled release | With release notes |
+| Low | Best-effort | Backlog | With release notes |
+
+Reports: `security@silverlabs.uk`, GPG key in `shared/signing/`.
+
+## What we publish (transparency)
+
+- **All source code** for our own components — open repos on `git.silverlabs.uk`
+- **Threat model** — `docs/threat-model.md`, updated when scope changes
+- **Reproducibility procedure** per-component
+- **SBOMs** per release
+- **Signing key fingerprints** and ceremony summaries
+- **Security advisories** — signed, dated, public archive
+- **Subpoena / law enforcement transparency report** — annual; we publish counts and what we had/didn't have
+- **Audit reports** — third-party audits published in full when commissioned
+
+## What we do *not* publish (and why)
+
+- **Active investigation details** — until coordinated disclosure window closes
+- **Per-user data** — we do not have most of it (minimum-data architecture); what we do have, we do not publish
+- **Server-side credential material** — for obvious reasons
+
+## Governance
+
+- This is a SilverLABS project; final calls rest with SilverLABS leadership
+- Security-critical decisions are documented (ADR-style) in `docs/decisions/` (to be created when first decision is needed)
+- Community contributions accepted via standard PR review with security-sensitive changes requiring a second reviewer
+
+## Honest acknowledgements
+
+- We are a small organisation. We will not match the auditor count of a Fortune-500 vendor
+- We use external upstream code (Kicksecure, GrapheneOS, Chromium, etc.) and inherit their trust assumptions
+- We cannot defend against every adversary; see [`threat-model.md`](threat-model.md) for what we do and do not target
+- Trust grows with track record; we expect to be audited and judged over time