bugfix(parser): Make macro a valid recovery terminal and tree token. - #10149

Summary

Fixes an ICE (Internal Compiler Error) that occurred when the macro keyword was used as a token inside an inline macro call (e.g., foo!(macro)). The TerminalMacro syntax kind was missing from the parser's token-tree leaf handling, causing a panic. Additionally, TerminalMacro was not included in the error recovery set of module-level keywords, meaning a macro declaration following a malformed item would not correctly stop error recovery.

Type of change

Please check one:

• Bug fix (fixes incorrect behavior)
• New feature
• Performance improvement
• Documentation change with concrete technical impact
• Style, wording, formatting, or typo-only change

Why is this change needed?

TerminalMacro was absent from the parser's token-tree leaf dispatch in parser.rs, so encountering macro as a leaf token inside an inline macro invocation caused an ICE. It was also missing from the module_item_kw! recovery macro in recovery.rs, so error recovery would not stop at a macro declaration boundary when recovering from a prior parse error.

What was the behavior or documentation before?

• Using macro as an argument to an inline macro call (e.g., foo!(macro)) caused an internal compiler error (panic).
• A macro declaration following a malformed item (e.g., const X with no type or value) would not act as a recovery boundary, potentially producing confusing cascading diagnostics.

What is the behavior or documentation after?

• foo!(macro) is parsed correctly without panicking; macro is treated as a TokenTreeLeaf with kind TokenMacro.
• Error recovery now stops at a macro keyword at module level, consistent with other module-item keywords like struct, fn, impl, etc.

Related issue or discussion (if any)

Regression fix for #10144.

Additional context

Two new test cases are added: one verifying the inline macro regression no longer ICEs, and one verifying that error recovery halts correctly at a following macro declaration.