Code block evals (#29619)

Add a targeted eval for code block formatting, and revise the system
prompt accordingly.

### Eval before, n=8

<img width="728" alt="eval before"
src="https://github.com/user-attachments/assets/552b6146-3d26-4eaa-86f9-9fc36c0cadf2"
/>

### Eval after prompt change, n=8 (excluding the new evals, so just
testing the prompt change)

<img width="717" alt="eval after"
src="https://github.com/user-attachments/assets/c78c7a54-4c65-470c-b135-8691584cd73e"
/>

Release Notes:

- N/A

assets/prompts/assistant_system_prompt.hbs

@@ -39,18 +39,78 @@ If appropriate, use tool calls to explore the current project, which contains th
 
 ## Code Block Formatting
 
-Whenever you mention a code block, you MUST use ONLY use the following format when the code in the block comes from a file
-in the project:
-
+Whenever you mention a code block, you MUST use ONLY use the following format:
 ```path/to/Something.blah#L123-456
 (code goes here)
 ```
-
 The `#L123-456` means the line number range 123 through 456, and the path/to/Something.blah
-is a path in the project. (If this code block does not come from a file in the project, then you may instead use
-the normal markdown style of three backticks followed by language name. However, you MUST use this format if
-the code in the block comes from a file in the project.)
-
+is a path in the project. (If there is no valid path in the project, then you can use
+/dev/null/path.extension for its path.) This is the ONLY valid way to format code blocks, because the Markdown parser
+does not understand the more common ```language syntax, or bare ``` blocks. It only
+understands this path-based syntax, and if the path is missing, then it will error and you will have to do it over again.
+Just to be really clear about this, if you ever find yourself writing three backticks followed by a language name, STOP!
+You have made a mistake. You can only ever put paths after triple backticks!
+<example>
+Based on all the information I've gathered, here's a summary of how this system works:
+1. The README file is loaded into the system.
+2. The system finds the first two headers, including everything in between. In this case, that would be:
+```path/to/README.md#L8-12
+# First Header
+This is the info under the first header.
+## Sub-header
+```
+3. Then the system finds the last header in the README:
+```path/to/README.md#L27-29
+## Last Header
+This is the last header in the README.
+```
+4. Finally, it passes this information on to the next process.
+</example>
+<example>
+In Markdown, hash marks signify headings. For example:
+```/dev/null/example.md#L1-3
+# Level 1 heading
+## Level 2 heading
+### Level 3 heading
+```
+</example>
+Here are examples of ways you must never render code blocks:
+<bad_example_do_not_do_this>
+In Markdown, hash marks signify headings. For example:
+```
+# Level 1 heading
+## Level 2 heading
+### Level 3 heading
+```
+</bad_example_do_not_do_this>
+This example is unacceptable because it does not include the path.
+<bad_example_do_not_do_this>
+In Markdown, hash marks signify headings. For example:
+```markdown
+# Level 1 heading
+## Level 2 heading
+### Level 3 heading
+```
+</bad_example_do_not_do_this>
+This example is unacceptable because it has the language instead of the path.
+<bad_example_do_not_do_this>
+In Markdown, hash marks signify headings. For example:
+    # Level 1 heading
+    ## Level 2 heading
+    ### Level 3 heading
+</bad_example_do_not_do_this>
+This example is unacceptable because it uses indentation to mark the code block
+instead of backticks with a path.
+<bad_example_do_not_do_this>
+In Markdown, hash marks signify headings. For example:
+```markdown
+/dev/null/example.md#L1-3
+# Level 1 heading
+## Level 2 heading
+### Level 3 heading
+```
+</bad_example_do_not_do_this>
+This example is unacceptable because the path is in the wrong place. The path must be directly after the opening backticks.
 ## Fixing Diagnostics
 
 1. Make 1-2 attempts at fixing diagnostics, then defer to the user.