[#245] Fix inconsistencies in TODO marker detection.

[c71n93]

Closes #245

This PR fixes a few inconsistencies in TODO / @todo marker detection.

After #232, some non-marker cases were already ignored, for example TODO, or TODOS. However, similar cases could still be treated as malformed puzzles through other matching paths.

Examples fixed by this PR:

final String METHOD_TODOS = "some text";
final String TODOS = "TODOS";

NAME="@todo"

@todo,

The fix makes these checks consistently require a trailing whitespace boundary before TODO / @todo is treated as a puzzle marker candidate.

[c71n93]

@yegor256 could you check this one please?

[yegor256]

@rultor merge

[rultor]

@rultor merge

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here.

[rultor]

@rultor merge

@c71n93 @yegor256 Oops, I failed. You can see the full log here (spent 2min).

    \u001b[32mGiven It is Unix\u001b[90m                                             # features/step_definitions/steps.rb:109\u001b[0m\u001b[0m
    \u001b[32mGiven I have a "\u001b[32m\u001b[1mtest.txt\u001b[0m\u001b[0m\u001b[32m" file with content:\u001b[90m                 # features/step_definitions/steps.rb:31\u001b[0m\u001b[0m
\u001b[32m      """\u001b[0m
\u001b[32m      \xBF test\u001b[0m
\u001b[32m      # @todo #44 \xFF hey\u001b[0m
\u001b[32m      \xFF test again\u001b[0m
\u001b[32m      """\u001b[0m
    \u001b[32mWhen I run bin/pdd with "\u001b[32m\u001b[1m--exclude=test.txt -v -f=/dev/null\u001b[0m\u001b[0m\u001b[32m"\u001b[90m # features/step_definitions/steps.rb:58\u001b[0m\u001b[0m
    \u001b[32mThen Stdout contains "\u001b[32m\u001b[1mExcluding test.txt\u001b[0m\u001b[0m\u001b[32m"\u001b[90m                    # features/step_definitions/steps.rb:64\u001b[0m\u001b[0m
    \u001b[32mThen Exit code is zero\u001b[90m                                       # features/step_definitions/steps.rb:89\u001b[0m\u001b[0m

Feature: Using .pdd config file
  As a source code writer I want to be able to
  call PDD as a command line tool and configure
  it via .pdd configuration file

  Scenario: Simple puzzles collecting                          \u001b[90m# features/uses_config.feature:8\u001b[0m
    \u001b[32mGiven I have a "\u001b[32m\u001b[1mSample.java\u001b[0m\u001b[0m\u001b[32m" file with content:\u001b[90m            # features/step_definitions/steps.rb:31\u001b[0m\u001b[0m
\u001b[32m      """\u001b[0m
\u001b[32m      @todo #13 Let's do it later, dude\u001b[0m
\u001b[32m      """\u001b[0m
    \u001b[32mAnd I have a "\u001b[32m\u001b[1m.pdd\u001b[0m\u001b[0m\u001b[32m" file with content:\u001b[90m                     # features/step_definitions/steps.rb:31\u001b[0m\u001b[0m
\u001b[32m      """\u001b[0m
\u001b[32m      --verbose\u001b[0m
\u001b[32m      --source=.\u001b[0m
\u001b[32m      --file=out.xml\u001b[0m
\u001b[32m      """\u001b[0m
/home/r/repo/lib/pdd/sources.rb:73: warning: undefining the allocator of T_DATA class FileMagic
    \u001b[32mWhen I run bin/pdd with "\u001b[32m\u001b[1m\u001b[0m\u001b[0m\u001b[32m"\u001b[90m                                 # features/step_definitions/steps.rb:58\u001b[0m\u001b[0m
    \u001b[32mThen Exit code is zero\u001b[90m                                     # features/step_definitions/steps.rb:89\u001b[0m\u001b[0m
    \u001b[32mAnd Stdout contains "\u001b[32m\u001b[1mReading from root dir .\u001b[0m\u001b[0m\u001b[32m"\u001b[90m              # features/step_definitions/steps.rb:64\u001b[0m\u001b[0m
    \u001b[32mAnd XML file "\u001b[32m\u001b[1mout.xml\u001b[0m\u001b[0m\u001b[32m" matches "\u001b[32m\u001b[1m/puzzles[count(puzzle)=1]\u001b[0m\u001b[0m\u001b[32m"\u001b[90m # features/step_definitions/steps.rb:73\u001b[0m\u001b[0m

28 scenarios (\u001b[32m28 passed\u001b[0m)
139 steps (\u001b[32m139 passed\u001b[0m)
0m9.845s
\u001b[1m\u001b[32m┌──────────────────────────────────────────────────────────────────────────────┐\u001b[0m\u001b[0m
\u001b[1m\u001b[32m│\u001b[0m\u001b[0m Share your Cucumber Report with your team at \u001b[4m\u001b[1m\u001b[36mhttps://reports.cucumber.io\u001b[0m\u001b[0m\u001b[0m     \u001b[1m\u001b[32m│\u001b[0m\u001b[0m
\u001b[1m\u001b[32m│\u001b[0m\u001b[0m                                                                              \u001b[1m\u001b[32m│\u001b[0m\u001b[0m
\u001b[1m\u001b[32m│\u001b[0m\u001b[0m Command line option:    \u001b[36m--publish\u001b[0m                                            \u001b[1m\u001b[32m│\u001b[0m\u001b[0m
\u001b[1m\u001b[32m│\u001b[0m\u001b[0m Environment variable:   \u001b[36mCUCUMBER_PUBLISH_ENABLED\u001b[0m=\u001b[36mtrue\u001b[0m                        \u001b[1m\u001b[32m│\u001b[0m\u001b[0m
\u001b[1m\u001b[32m│\u001b[0m\u001b[0m cucumber.yml:           \u001b[36mdefault: --publish\u001b[0m                                   \u001b[1m\u001b[32m│\u001b[0m\u001b[0m
\u001b[1m\u001b[32m│\u001b[0m\u001b[0m                                                                              \u001b[1m\u001b[32m│\u001b[0m\u001b[0m
\u001b[1m\u001b[32m│\u001b[0m\u001b[0m More information at \u001b[4m\u001b[1m\u001b[36mhttps://cucumber.io/docs/cucumber/environment-variables/\u001b[0m\u001b[0m\u001b[0m \u001b[1m\u001b[32m│\u001b[0m\u001b[0m
\u001b[1m\u001b[32m│\u001b[0m\u001b[0m                                                                              \u001b[1m\u001b[32m│\u001b[0m\u001b[0m
\u001b[1m\u001b[32m│\u001b[0m\u001b[0m To disable this message, specify \u001b[1mCUCUMBER_PUBLISH_QUIET=true\u001b[0m or use the      \u001b[1m\u001b[32m│\u001b[0m\u001b[0m
\u001b[1m\u001b[32m│\u001b[0m\u001b[0m \u001b[1m--publish-quiet\u001b[0m option. You can also add this to your \u001b[1mcucumber.yml:\u001b[0m          \u001b[1m\u001b[32m│\u001b[0m\u001b[0m
\u001b[1m\u001b[32m│\u001b[0m\u001b[0m \u001b[1mdefault: --publish-quiet\u001b[0m                                                     \u001b[1m\u001b[32m│\u001b[0m\u001b[0m
\u001b[1m\u001b[32m└──────────────────────────────────────────────────────────────────────────────┘\u001b[0m\u001b[0m
Running RuboCop...
Inspecting 28 files
\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m\u001b[32m.\u001b[0m

28 files inspected, \u001b[32mno offenses\u001b[0m detected
Running xcop...
Inspecting 3 files...
\u001b[32m.\u001b[0minvalid byte sequence in US-ASCII
invalid byte sequence in US-ASCII
container e7488160b3f111c3c7fbe92d837b6e4bb4750aa815f3f1eb0539110fea226b99 is dead
Wed May 13 10:52:40 UTC 2026

[c71n93]

@yegor256 Looks like the rultor failure is caused by the xcop check, which is unrelated to the changes in this PR.
Has this issue with xcop been resolved yet?