Phase 0: lock platform contract, naming convention, and style enforcement

Establishes the framework's foundation as a multi-site adoptable platform.

ADRs (migrations/adr/):
- ADR-001 (ACCEPTED): Asset is the platform contract; Machine retires.
  Three relationship types (partof, controls, connectedto) with free-text
  label, position-resolution chain (asset > related > location),
  hierarchical locations, sibling-bay propagation.
- ADR-002 (ACCEPTED): Plugin contract semver via __contract_version__.
- ADR-003 (ACCEPTED): Hybrid plugin distribution (in-tree bundled +
  filesystem-based external).
- ADR-004 (ACCEPTED): Per-site instances, not multi-tenant.
- ADR-005 (ACCEPTED): Equipment plugin (manufacturing) split from
  measuringtools plugin (metrology). Subtype-table pattern for protocol
  data (FOCAS, CLM, MTConnect).
- ADR-006 (ACCEPTED): Plugin collector contract via get_collector_schema
  hook with API-key auth and identity-based upsert.

Naming convention v1 (CONTRIBUTING.md):
- DB tables/columns: lowercase concatenated, no underscores or dashes
- DB-mirrored Python/JS variables match column names exactly; pure code
  follows host-language convention (PEP 8 / camelCase)
- Closed acronym allowlist (universal + shop-floor domain), banned
  shorthand list with suffix exception (printers_bp etc allowed)
- Plain ASCII everywhere: chat, docs, comments, string literals

Style enforcement (scripts/check-naming-and-style.sh):
- Pre-commit-runnable check script: non-ASCII, banned shorthand,
  snake_case DB names, snake_case API params in frontend
- Fixes 14 violations across 11 files (Unicode arrows, snake_case
  params, ctx -> canvasContext, res -> response, req -> request_obj)

Project state (CLAUDE.md, README.md, frontend/CLAUDE.md):
- De-staled CLAUDE.md to reflect actual current state
- README unifies DB story (MySQL canonical, SQLite test-only)
- frontend/CLAUDE.md points at root convention

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

migrations/adr/README.md

@@ -0,0 +1,25 @@
+# Architecture Decision Records
+
+Each ADR captures a single architectural decision: the context, the decision itself, the consequences, and the alternatives considered. ADRs are immutable once accepted. Superseded ADRs stay in this folder with a pointer to the newer ADR.
+
+## Status definitions
+
+- **PROPOSED**: drafted, awaiting decision
+- **ACCEPTED**: decision is in effect
+- **SUPERSEDED**: replaced by a later ADR (link forward)
+- **DEPRECATED**: no longer in effect, no replacement
+
+## Index
+
+| ADR | Title | Status |
+|-----|-------|--------|
+| [001](ADR-001-asset-as-platform-contract.md) | Asset model is the platform contract | ACCEPTED |
+| [002](ADR-002-plugin-versioning.md) | Plugin contract versioning (semver) | ACCEPTED |
+| [003](ADR-003-plugin-distribution.md) | Plugin distribution model | ACCEPTED |
+| [004](ADR-004-deployment-topology.md) | Deployment topology (per-site instances) | ACCEPTED |
+| [005](ADR-005-equipment-vs-measuringtools.md) | Equipment vs measuringtools plugin scope | ACCEPTED |
+| [006](ADR-006-collector-contract.md) | Plugin collector contract pattern | ACCEPTED |
+
+## Authoring
+
+When proposing a new decision, copy the most recent ADR as a template, increment the number, and update this index. Do not edit accepted ADRs in place; supersede them with a new one.