docs: retire repo-mem MCP, migrate skills to .claude/skills, audit fixes

- Delete .mcp.json + .claude/rules/repo-mem.md; drop .repo-mem from .gitignore
- Remove repo-mem / substrate_score / repo_search references from all .md
- Move 15 EVOLV skills from .agents/skills/ to .claude/skills/ so they are
  auto-discovered by the Claude Code harness and invokable via the Skill tool
- Retire .agents/skills/evolv-orchestrator (duplicate of the subagent at
  .claude/agents/evolv-orchestrator.md); orchestrator lives as a subagent only
- Drop OpenAI-format agent yaml metadata from each skill (not needed for CC)
- Update CLAUDE.md, CONTRACTS.md, AGENTS.md to point at the new locations and
  disambiguate skills (.claude/skills/) vs subagents (.claude/agents/)
- Fix CLAUDE.md tick-loop wording (opt-in per-node, not a fixed 1000ms)
- Widen .claude/rules/ paths frontmatter so node-architecture and telemetry
  rules trigger on more relevant files; add frontmatter to flow-layout rule
- Bump CONTRACTS.md review date to 2026-05-19; add step 7 to the contract-
  change workflow (review example flows when topic usage changes)
- Bump nodes/generalFunctions pin (Home.md substrate_score reference removed)

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

.claude/skills/evolv-mechanical-rotating-equipment/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: evolv-mechanical-rotating-equipment
+description: Provide rotating equipment engineering guidance for EVOLV machine and pumping logic. Use when implementing or reviewing `rotatingMachine`, `machineGroupControl`, pump/motor behavior, operating envelopes, efficiency/power curves, surge/choke limits, and physically plausible constraints in node domain logic.
+---
+
+# EVOLV Mechanical Rotating Equipment
+
+## Mission
+Keep rotating equipment behavior physically plausible, safe, and diagnosable in EVOLV JavaScript domain classes.
+
+## Harness Execution Contract
+- Start from equipment assumptions and current curve/sensor sources in repo.
+- Define invariants before edits:
+  - physical plausibility constraints remain enforced
+  - degraded/fail-safe behavior remains explicit
+  - outputs remain diagnosable for operations teams
+- Validate with boundary-condition evidence and deterministic test outcomes.
+
+## Scope
+- `nodes/rotatingMachine/`
+- `nodes/machineGroupControl/`
+- `nodes/pumpingStation/`
+- Related shared curve/model datasets in `nodes/generalFunctions/datasets/assetData/`
+
+## Engineering Checklist
+1. Validate units and conversions before algorithm changes.
+2. Enforce operating envelope constraints:
+- min/max speed
+- flow/head boundaries
+- power/torque limits
+- efficiency range sanity
+3. Prevent impossible states (negative flow where not allowed, non-physical efficiencies, unstable mode transitions).
+4. Define clear degraded behavior for out-of-range inputs.
+5. Preserve interpretability: outputs should map to recognizable mechanical concepts.
+
+## Implementation Pattern
+- Keep mechanics in `src/specificClass.js`.
+- Keep Node-RED concerns in `src/nodeClass.js`.
+- Use shared helpers from `generalFunctions` for logging/config assertions.
+
+## Test Expectations
+Add/adjust tests under node-specific `test/` for:
+- boundary conditions
+- invalid sensor/input combinations
+- regression of known machine edge cases
+- deterministic output under repeated ticks
+
+## Deliverables
+Return:
+- assumptions about equipment type and curve source
+- implemented constraints and rationale
+- test coverage for boundary cases
+- remaining mechanical uncertainties requiring field data
+
+Decision interview triggers:
+- safety envelope changes (speed, power, flow/head boundaries)
+- curve-source replacement with uncertain field alignment
+- degraded-mode changes that affect availability vs protection tradeoffs