docs(qfd): introduce Functions layer and GLOSSARY.md ontology

The doc previously conflated functions (transformations the device
performs) with characteristics (measurable attributes). Surfacing
Functions as their own ontology layer makes HOW names — which pack
a function reference plus an attribute — readable without function
definitions staying implicit.

- new GLOSSARY.md at root: 5-layer ontology stack (WHAT / Function /
  Characteristic / Metric+Unit / Target), peer to CONTEXT.md
  (device-specific vocabulary)
- qfd.md §2 opens with a Functions inventory (Type, Save, Publish,
  Recover, Boot, Provision); Render and Reconnect noted as
  sub-functions; Provision flagged as build-time-only in v0.1
- H1 "Keypress → glyph latency" → "Type latency (keypress → glyph)"
- H4 "Cold boot → cursor ready" → "Boot latency (cold)"
  (the arrow transformation moves to the Functions inventory; the
  parenthetical keeps the residual qualifier)
- cascade through §3 priority list, §6 critical-performance-budget
  rows for H1/H4, §8 inconsistencies, and quality-house.md TikZ
  column labels

Matrix cell strengths held; no Σ recompute.

docs/quality-house.md

@@ -325,18 +325,18 @@ market"), not as a fair head-to-head buyer's guide.
 
   % ---------- HOWs (rotated column titles) ----------
   \foreach \c/\t in {%
-    1/{H1 Keypress$\to$glyph latency},
+    1/{H1 Type latency},
     2/{H2 Refresh area per keystroke},
     3/{H3 Full-refresh cadence},
-    4/{H4 Cold boot to cursor},
+    4/{H4 Boot latency (cold)},
     5/{H5 Continuous-typing endurance},
-    6/{H6 Push success rate},
-    7/{H7 Push end-to-end time},
-    8/{H8 Save durability vs power loss},
+    6/{H6 Publish reliability},
+    7/{H7 Publish latency},
+    8/{H8 Save durability},
     9/{H9 PSRAM heap headroom},
     10/{H10 Firmware binary size},
     11/{H11 Total stack budget},
-    12/{H12 Wi-Fi reconnect time},
+    12/{H12 Network reconnect time},
     13/{H13 Idle / typing / push current},
     14/{H15 Clean release build time}%
   }
@@ -642,7 +642,7 @@ picture.
 - **Basement rows** are: v0.1 target → §3 column sum (`Σ` of
   `weight × strength`) → relative weight as integer % of total (1557).
   Relative weights round to 100.
-- **H7, H10, H15** (push time, binary size, build time) sit at the bottom
+- **H7, H10, H15** (Publish latency, binary size, build time) sit at the bottom
   of the basement — knowingly-paid costs per `qfd.md` §7, not signals to
   optimise harder.