Strip implementation details from AC; add design-independence rule

acceptance_criteria.md and restrictions.md were carrying internal
component selections (DINOv2/SuperPoint/FAISS/ESKF), library pins
(pymavlink/MAVSDK), autopilot parameter values (GPS1_TYPE=14,
EK3_SRC1_*, VISO_QUAL_MIN), and v1/v1.1 phasing tied to specific
ArduPilot PR numbers. Per IEEE 830 / Atlassian / GitScrum,
acceptance criteria must be design-independent — outcomes only,
not implementation. Cleaned both files (-35% combined size) while
preserving every testable threshold and contract bullet.

Output-schema label renamed: vo_extrapolated -> visual_propagated.
FC scope broadened from ArduPilot-only to ArduPilot + iNav (both
via standard MAVLink external-positioning interfaces).

Encoded the lesson into the two skills that write/refine AC:
- problem/SKILL.md (initial AC production)
- research/steps/01_mode-a-initial-research.md (Phase 1 AC
  & Restrictions Assessment)

Autodev state reset to greenfield Step 2 (Research) for the
post-restart greenfield run; cycle 1, in-progress at sub-step
ac-restrictions-assessment.

Co-authored-by: Cursor <cursoragent@cursor.com>

_docs/_autodev_state.md

@@ -0,0 +1,13 @@
+# Autodev State
+
+## Current Step
+flow: greenfield
+step: 2
+name: Research
+status: in_progress
+sub_step:
+  phase: 1
+  name: ac-restrictions-assessment
+  detail: "Mode A — reading problem context, preparing AC/restrictions assessment"
+retry_count: 0
+cycle: 1