fix(prompts): make the layout engine the default path, not display_diagram

"Generate a diagram to illustrate the git operation" still produced
hand-written XML. Root cause: the very first working instruction in the
system prompt said "then use display_diagram tool to generate the XML" —
unconditionally. The tool-routing rules that divide by layout shape only
appear 70 lines later, so the earlier, more actionable instruction won.
That line predates draw_graph and restructure_diagram, from when
display_diagram was the only drawing tool.

- The opening instruction now says to pick the tool by layout shape, and
  names the engine tools as the default with display_diagram as the
  exception.
- The identity line no longer describes the job as "precise XML
  specifications".
- draw_graph's examples (prompt and tool description) now include
  git/branching workflows and the "illustrate how X works" phrasing.
- "Core capabilities" and "Layout constraints" are scoped to
  display_diagram — they read as instructions to hand-position everything.
- The edit_diagram error-recovery note no longer funnels back to
  display_diagram for restructuring.
- display_diagram's own tool description now states it is the exception
  and points to draw_graph / restructure_diagram.

lib/system-prompts.ts

@@ -9,11 +9,11 @@
 // Default system prompt (~1900 tokens) - works with all models
 export const DEFAULT_SYSTEM_PROMPT = `
 You are an expert diagram creation assistant specializing in draw.io XML generation.
-Your primary function is chat with user and crafting clear, well-organized visual diagrams through precise XML specifications.
+Your primary function is chat with user and crafting clear, well-organized visual diagrams. You declare the structure and a layout engine computes the geometry; for a small class of diagrams you write the XML yourself.
 You can see images that users upload, and you can read the text content extracted from PDF documents they upload.
 ALWAYS respond in the same language as the user's last message.
 
-When you are asked to create a diagram, briefly describe your plan about the layout and structure to avoid object overlapping or edge cross the objects. (2-3 sentences max), then use display_diagram tool to generate the XML.
+When you are asked to create a diagram, briefly describe your plan about the layout and structure (2-3 sentences max), then pick the tool by the diagram's LAYOUT SHAPE — see "Choosing the right tool" below. Most diagrams go through draw_graph or restructure_diagram, which compute the layout for you; display_diagram (hand-written XML) is the exception, reserved for diagrams whose exact positions ARE the content.
 After generating or editing a diagram, you don't need to say anything. The user can see the diagram - no need to describe it.
 
 ## App Context
@@ -80,11 +80,17 @@ parameters: {
 }
 ---End of tools---
 
-IMPORTANT: Choose the right tool. Divide by the diagram's LAYOUT SHAPE, not by which icon set it uses.
+## Choosing the right tool
+
+IMPORTANT: Divide by the diagram's LAYOUT SHAPE, not by which icon set it uses. The engine
+tools (draw_graph, restructure_diagram) are the DEFAULT: they compute every coordinate, size
+and arrow route, so nothing overlaps and no arrow cuts through a box. Hand-written XML via
+display_diagram is the exception, not the default.
 
 Use draw_graph when the diagram is boxes joined by arrows and the arrows define the order:
   flowcharts, decision trees, process diagrams, approval flows, CI/CD pipelines, state machines,
-  dependency graphs, ER diagrams, site maps, data-flow diagrams.
+  git/branching workflows, dependency graphs, ER diagrams, site maps, data-flow diagrams,
+  and any "illustrate how X works" where X is a sequence of steps or states.
   You supply only nodes and edges. Do NOT try to lay these out yourself and do NOT write XML for
   them — a flowchart written as XML or as nested containers comes out as one column, which forces
   every branch to jump over the step beside it.
@@ -143,17 +149,12 @@ Flowchart box shapes, for both draw_graph and add_box:
   diamond to mean a choice, so drawing every step as the same rectangle loses that.
 
 Core capabilities:
-- Generate valid, well-formed XML strings for draw.io diagrams
 - Create professional flowcharts, mind maps, entity diagrams, and technical illustrations
-- Convert user descriptions into visually appealing diagrams using basic shapes and connectors
-- Apply proper spacing, alignment and visual hierarchy in diagram layouts
-- Adapt artistic concepts into abstract diagram representations using available shapes
-- Optimize element positioning to prevent overlapping and maintain readability
+- Convert user descriptions into visually appealing diagrams
 - Structure complex systems into clear, organized visual components
+- Generate valid, well-formed XML strings, for the diagrams that need display_diagram
 
-
-
-Layout constraints:
+Layout constraints (for display_diagram only — the engine tools compute layout themselves):
 - CRITICAL: Keep all diagram elements within a single page viewport to avoid page breaks
 - Position all elements with x coordinates between 0-800 and y coordinates between 0-600
 - Maximum width for containers (like AWS cloud boxes): 700 pixels
@@ -387,7 +388,7 @@ Delete container (children & edges auto-deleted):
 \`\`\`
 
 **Error Recovery:**
-If cell_id not found, check "Current diagram XML" for correct IDs. Use display_diagram if major restructuring is needed
+If cell_id not found, check "Current diagram XML" for correct IDs. If major restructuring is needed, pick the tool by layout shape (draw_graph / restructure_diagram / display_diagram) as usual