feat(base2): add meta-rule 'Syntax ≠ logic' to General guidelines

[chicagoist]

General principle: parser passes (node --check, tsc --noEmit, etc.)
do NOT mean the code works. Always verify execution, not just parsing.

Placed before the JavaScript Debugging rule (#872) as the axiom
from which the JS-specific verification steps follow.

Diff

 }
+- **Syntax ≠ logic:** `node --check`, `tsc --noEmit`, or any parser
+  pass does NOT mean the code works — always verify that code
+  executes, not just that it parses.
+- **JavaScript Debugging:** After fixing JS syntax errors, do NOT
+  stop at `node --check` passing — the code may be syntactically
+  valid but logically dead. Verify: (1) every `querySelector(All)`
+  target exists in the HTML body, (2) execution reaches every
+  `addEventListener` (trace from IIFE entry through all wrapping
+  `if` conditions), (3) no `if (elements.length > 0)` guard wraps
+  live logic around removed DOM elements.

[codebuff-team]

The instinct here is fine — reminding the agent that a parser pass doesn't guarantee runtime correctness is a legitimate point, and it's a tiny, low-risk diff to agents/base2/base2.ts. That said, a few things hold this back from being a clean port:

1. The bundled 'JavaScript Debugging' rule is extremely specific (querySelector/addEventListener/IIFE tracing) — it reads like it was written to fix one particular bug you hit, not a generally-applicable guideline. That level of specificity doesn't generalize well to the other languages/frameworks base2 needs to handle, and it bloats the general guidelines section with a narrow DOM-debugging checklist.
2. There's no evidence this was tested against actual agent behavior (e.g. before/after transcripts showing the agent skipping execution checks). Prompt-engineering changes like this are hard to verify without some kind of eval, and the PR body doesn't include any.
3. "Syntax ≠ logic" as a standalone axiom is fine, but pairing it permanently with a hyper-specific JS/DOM debugging playbool conflates a general principle with implementation-specific advice — these probably shouldn't be merged into one bullet-pair without more general framing.

If you separate the general axiom (which is easy to justify) from the JS-specific checklist (which needs either broadening or evidence it prevents a recurring class of bugs), this would be much easier to port as-is. Consider trimming the second bullet to be shorter and more general, or dropping it if it was written for a single incident.