codelinks: One-line marker scanner triggers on @-mentions anywhere in a comment line, not just at line start

[HartmannNico]

Bug description

The sphinx-codelinks one-line marker scanner looks for @ anywhere in a comment line. If an @-containing word is followed by a comma later on the same line, the scanner interprets the text as a malformed marker and raises InvalidNeedException: Given ID '...' does not match configured regex

To reproduce

Any Rust source comment of the form:

// Some prose that mentions @@another-tag(item_1, item_2): more text
// See @author, check the example
// We parse things matching @pattern, then act

…fails the build if the field between the first comma and the next comma/end-of-line doesn't match the configured ID regex.

Current behaviour

Scans for @ at any position in the comment text. Treats everything before the first comma as the title and everything between the first and second comma as the ID. Build fails when the "ID" contains spaces or special characters.

Expected behaviour

Only parse a line as a one-line marker when @ appears at the start of the meaningful comment content — i.e., the line matches ^\s*//!?\s*@<title>,\s*<id>,\s*<type>,\s*\[<links>\]. An @ embedded in the middle of free-form prose should be ignored.

[ubmarco]

Root cause: the one-line scanner finds the start sequence (@) with str.find, matching it anywhere in a comment. When @ sits in prose before a comma, everything after it is parsed as title, id, … and the malformed id (spaces/specials) trips the sphinx-needs id regex → InvalidNeedException.

Quick workaround (no upgrade needed): switch the project to a self-delimiting bracket style, which doesn't collide with @ in prose. Markers become // [[Title, ID, impl, [links]]]:

[codelinks.projects.<name>.analyse.oneline_comment_style]
start_sequence = "[["
end_sequence   = "]]"

Proper fix: #89 anchors newline-terminated markers to the start of the comment content — only comment decoration (//, #, *, …) may precede the start sequence, so an @ embedded in prose is ignored. Self-delimiting bracket styles stay position-independent. The same fix is mirrored in ubCode to keep both parsers consistent.