test(spec): record what changed the whitespace-only admission, beside its assertions

The same stale ground as the docblock, three lines from the symbol: the case
admitted a blank structural condition as "not authored on both sides", which
#15807 and #17322 ended. The two assertions are unchanged and still correct —
they pin that this function does NOT carry the blank rule — and the comment now
says so instead of restating a ruling that no longer holds.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MkQhmuuJAVDjmeWNixwDDH

Author: claude

packages/spec/src/automation/flow-node-expression-paths.test.ts

@@ -267,8 +267,13 @@ describe('every pre-#14149 entry resolves byte-identically (the ratchet\'s fixtu
     it('admits every string — what it SAYS is validateExpression\'s business', () => {
       expect(structuralConditionRefusal('record.rating >= 4')).toBeUndefined();
       expect(structuralConditionRefusal('{record.rating} >= 4')).toBeUndefined();
-      // Ruled correct, not a defect: a whitespace-only STRING means "not
-      // authored" on both sides and stays so.
+      // Still admitted — but on the SHAPE question only, and no longer because
+      // the blank is correct. #15662 admitted it as "not authored on both
+      // sides"; #15807 refused it at the edge door and #17322 rebound the node
+      // door at `registerFlow`, so a blank structural condition IS a defect
+      // today. It is refused there by the imported evaluated-slot rule sitting
+      // BESIDE this one, never by this function — which is exactly what these
+      // two assertions pin. See the docblock of `structuralConditionRefusal`.
       expect(structuralConditionRefusal('   ')).toBeUndefined();
       expect(structuralConditionRefusal('')).toBeUndefined();
     });