Fix critical architecture review issues

Critical fixes:
- Rename qualityDegradation → qualityRetention across all docs
  (semantically inverted: 0.9 meant 90% quality RETAINED, not 90%
  degradation). Updated schemas, graph-model, cost-benefit, ADRs.
- Add TaskInput → TaskGraphNodeAttributes transformation section
  to graph-model.md, documenting how Nullable(Optional) input fields
  map to Optional graph attributes
- Fix DuplicateEdgeError fields: source/target → prerequisite/dependent
  to match the established edge direction convention
- Fix resolveDefaults signature: Partial<TaskGraphNodeAttributes>
  → Partial<...> & Pick<TaskGraphNodeAttributes, 'name'> to
  require the name field
- Move Nullable helper definition before its first use in schemas.md
- Fix 'construction never throws' contradiction: rephrase to
  'construction enforces uniqueness, not data quality'
- Define all 6 enum value sets in schemas.md (previously only
  TaskScope and TaskRisk were explicit)
- Add EvConfig parameter table with defaults and semantics
- Document WorkflowCostOptions.limit parameter
- Add construction error handling table to graph-model.md
- Add graph.raw mutation safety warning to api-surface.md
- Update build-distribution.md error class list to include
  DuplicateNodeError and DuplicateEdgeError

docs/architecture/decisions/005-no-depth-escalation-v1.md

@@ -15,7 +15,7 @@ In the DAG-propagation model, each hop compounds another `<1.0` factor. This imp
 ### Positive
 - No double-counting of depth effects
 - Simpler model to explain, implement, and debug
-- Architecture supports future depth-escalation via per-edge `qualityDegradation` adjustments or `risk` categorical escalation without API changes
+- Architecture supports future depth-escalation via per-edge `qualityRetention` adjustments or `risk` categorical escalation without API changes
 
 ### Negative
 - May underestimate cost for very deep dependency chains where risk genuinely escalates with depth
@@ -23,4 +23,4 @@ In the DAG-propagation model, each hop compounds another `<1.0` factor. This imp
 
 ### Future
 
-If empirical data from actual task outcomes shows that depth-escalation is needed, it can be added without API changes — either by adjusting `qualityDegradation` per depth, or by escalating the `risk` categorical. This is a calibration question, not an architecture question.
+If empirical data from actual task outcomes shows that depth-escalation is needed, it can be added without API changes — either by adjusting `qualityRetention` per depth, or by escalating the `risk` categorical. This is a calibration question, not an architecture question.