MVP M7: Socrates can propose model changes — review impact + Accept/Reject

The dock now has a "propose" button that asks Socrates to suggest one
high-value structural change. He returns a structured payload (reasoning
+ ops + impactSummary) which renders as a ProposalCard inline in the
thread. Accept routes the ops through the same useApply() pipeline as
user-originated edits (optimistic local + persisted POST + server
reconciliation).

apps/web/lib/llm/prompts/socrates/propose.md
- Promoted verbatim from phase-0/src/prompts/.

apps/web/lib/llm/proposeChange.ts
- Server-side proposeChange() — calls the LLM with character + propose
  prompts + trimmed model + active issues. JSON Schema uses oneOf per
  op kind (Phase 0 lesson: small models need this to produce real op
  shapes instead of cramming everything into the kind name).
- normalizeOps() converts the LLM-emitted op shapes into canonical
  ModelOp[] (fills in property ids/multiplicity defaults, expands
  satisfiedBy[] into RequirementRelation[], splits PropertyType union
  per kind).

apps/web/lib/sysml/impact.ts
- Pure pre-apply impact analysis. Runs the ops through the same
  applyOps() reducer locally, then diffs:
    - structural: added / removed / changed elements (per kind)
    - validation: issues created vs resolved (by canonical issue key)
    - dep-graph blast radius (closure of touched element ids on the
      post-apply graph)
  Headline stats summarized as deltas (+1 block, −1 assoc, etc.) for
  the proposal card.

apps/web/app/api/projects/[projectId]/socrates/propose
- POST: returns { reasoning, ops, impactSummary, meta }. Pure read of
  the model — does not apply anything; client must POST /apply with the
  same ops to commit.

apps/web/components/socrates/ProposalCard.tsx
- In-dock card: PROPOSAL tag + delta stats / reasoning / collapsible
  ops list / Impact section (added/removed/changed) / Validation diff
  (resolves ✓ / creates ⚠) / Accept + Reject. Disabled when impact
  analysis flagged the apply as illegal.

apps/web/components/socrates/SocratesDock.tsx
- New "propose" button between the input field and send. Renders
  ProposalCard for assistant turns of role "proposal". Accept calls
  useApply(); on success the card collapses to a "✓ Applied" system
  bubble. On apply failure the dock shows the structured error
  messages.
- New "system" bubble role for apply confirmations + dismissals.

apps/web/components/diagram-canvas/DiagramCanvas.tsx
- Bug fix: new blocks/constraints arriving via the model→RF sync (e.g.
  from accepted proposals) are now positioned to the right of the
  existing layout instead of stacking at (0, 0) offscreen.

apps/web/lib/sync/ModelStore.tsx
- Bug fix / observability: background-POST failures and version
  mismatches now log to the console with structured context instead of
  being silently swallowed. The server's authoritative state still
  replaces the optimistic local state on response, but the user can now
  see why their accept appeared to do nothing (typically: page tab
  was at version N but server had advanced to N+1).

apps/web/components/diagram-canvas/DiagramCanvas.tsx

@@ -118,11 +118,14 @@ function DiagramInner({ data, focusBlockId, onSelect, issuesByElement }: Diagram
       const byId = new Map(currentNodes.map(n => [n.id, n]));
       const next: Node<BlockNodeData>[] = [];
 
-      // Existing model elements first — preserve position & selection from RF state
+      // For new elements added by the model (e.g. accepted proposals), drop
+      // them at a sensible spot near the existing centroid so they're
+      // immediately visible — not at (0,0) offscreen.
+      const placeNew = makePlaceNewPosition(currentNodes);
+
       for (const b of model.blocks) {
         const existing = byId.get(b.id);
         if (existing) {
-          // Update data only if it changed (cheap structural compare)
           const propNames = b.properties.map(p => p.name);
           const dataChanged =
             existing.data?.label !== b.label ||
@@ -134,8 +137,7 @@ function DiagramInner({ data, focusBlockId, onSelect, issuesByElement }: Diagram
             next.push(existing);
           }
         } else {
-          // New block from outside (rare in M5; mostly self-originated drops)
-          next.push(makeNodeForBlock(b));
+          next.push({ ...makeNodeForBlock(b), position: placeNew() });
         }
       }
       for (const c of model.constraints) {
@@ -151,7 +153,7 @@ function DiagramInner({ data, focusBlockId, onSelect, issuesByElement }: Diagram
             next.push(existing);
           }
         } else {
-          next.push(makeNodeForConstraint(c));
+          next.push({ ...makeNodeForConstraint(c), position: placeNew() });
         }
       }
       return next;
@@ -521,6 +523,28 @@ function makeEdgeForApplies(constraintId: string, targetBlockId: string): Edge<S
   };
 }
 
+/**
+ * Position factory for newly-arrived nodes — places each at the right edge of
+ * the existing layout, stacked vertically, so they're visible without panning.
+ * Falls back to a fixed offset when there are no existing nodes.
+ */
+function makePlaceNewPosition(existing: { position: { x: number; y: number } }[]): () => { x: number; y: number } {
+  let baseX = 100;
+  let baseY = 100;
+  if (existing.length > 0) {
+    const maxX = Math.max(...existing.map(n => n.position.x));
+    const minY = Math.min(...existing.map(n => n.position.y));
+    baseX = maxX + 240;
+    baseY = minY;
+  }
+  let i = 0;
+  return () => {
+    const pos = { x: baseX, y: baseY + i * 140 };
+    i++;
+    return pos;
+  };
+}
+
 function snapshotIds(model: SysMLModel): { blocks: Set<string>; assocs: Set<string>; constraints: Set<string> } {
   return {
     blocks: new Set(model.blocks.map(b => b.id)),