Fix phantom "Important:" header stealing a taking-fire report's deadline

Turned out to be one bug, not two: "Answer by <time>" phrasing was
already covered by _TAKING_FIRE_TIME_RE ('before|by <time>'). The real
bug was the last-resort bare-"<Name>:" header fallback matching a
same-message "Important:" follow-up line as a brand new named entity
(nothing excluded common prose lead-ins), creating a bogus
Target#Important that stole the deadline into its own requested_time
instead of the real report's. Fixed with a blocklist on that fallback
rule (important/note/warning/attention/caution/alert/reminder/priority).
New regression test, 55 total passing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

TODO.md

@@ -333,21 +333,22 @@ each confirmed live against the real VM, not just read off a diff:
       fixing: does the board/firing-panel data model even have a place
       to put a second shell for one strike request, or does this need a
       new field/shape entirely?
-- [ ] "Answer by 10:30:00" isn't recognized as a deadline at all --
-      `_TAKING_FIRE_TIME_RE`/`_REQUESTED_BEFORE_RE` only know "before/by
-      \<time\>" and "Requested before - \<time\> -" phrasing. A third
-      deadline grammar to add.
-- [ ] A same-message "Important: ... Answer by \<time\>" follow-up line
-      gets misread as a brand new named entity header (the last-resort
-      bare-`<name>:` fallback rule matches "Important:"), creating a
-      bogus `Target#Important` carrying that deadline as its own
-      `requested_time`. Real false-positive in the header-detection
-      fallback, needs either an exclusion list (blocklist "Important"
-      and similar prose lead-ins) or a stricter bare-header shape.
-      Confirmed live against the user's real pasted message (with an
+- [x] "Answer by 10:30:00" turned out to be one bug, not two. The
+      phrasing itself was never the problem -- `_TAKING_FIRE_TIME_RE`
+      already matches any `before|by <time>`, "Answer BY 10:30:00"
+      included. The REAL bug: a same-message "Important: ..." follow-up
+      line was misread as a brand new named entity header (the
+      last-resort bare-`<name>:` fallback rule matched "Important:"
+      itself with nothing excluding common prose lead-ins), creating a
+      bogus `Target#Important` that stole "Answer by 10:30:00" into ITS
+      own `requested_time` instead of the real report's. Fixed with a
+      blocklist (`_BARE_NAME_HEADER_BLOCKLIST`: important/note/warning/
+      attention/caution/alert/reminder/priority) on that fallback rule --
+      once the phantom split stopped happening, the deadline resolved
+      onto the right entry with no separate fix needed. New regression
+      test, confirmed against the user's real pasted message (with an
       assumed `Infantry#N taking fire!` header line prepended, since
-      their paste seems to have been cropped before it -- worth
-      double-checking against the actual full in-game message).
+      their paste seems to have been cropped before it).
 
 - [x] "\<Type\>#\<id\> Destroyed" kill-feed parsing already exists and
       already marks the matching Target dead (`parse_destroyed`,