[Enhancement] IntelliJ: pass -I/--parseinclude and -N/--name when running tests (VS Code parity)

[d-biehl]

Summary

The IntelliJ plugin does not yet pass Robot Framework's -I / --parseinclude nor -N / --name options when running a test / task or a subset of tests. The VS Code extension already does. This is a parity gap — the IntelliJ platform support lags a bit behind the VS Code implementation.

Without these options, on Robot Framework 6.1+ a subset run parses the whole project instead of only the selected file(s), which can surface parse errors from unrelated files ("widening scope"). Implementing them brings the IntelliJ run behaviour in line with VS Code (see #624 for the VS Code side).

Where

intellij-client/src/main/kotlin/dev/robotcode/robotcode4ij/execution/RobotCodeRunProfileState.kt, startProcess().

The command is currently assembled as:

-dp . debug [--tcp <port>] [--no-debug] -bl <longname> [-bl <longname> ...]

Only -bl (by-longname) is added per selected item — no -N, no -I.

Proposed

Mirror what the VS Code extension does in DebugManager.runTests
(vscode-client/extension/debugmanager.ts):

• -N <topLevelSuiteName> — the discovered top-level suite name, so the -bl longnames computed at discovery time stay valid at run time (the runner's ByLongName modifier remaps them via --name).
• -I <relSource> per selected source file — but only when the project's Robot Framework supports --parseinclude (RF ≥ 6.1).

Available building blocks

• RobotCodeTestManager.supportsParseInclude (per-project flag) already exists — it was added alongside the [Bug] New version of RobotCode 2.6.* misses option -I in terminal command which causes errors #624 fix and is fed from the discovery result's supportsParseInclude.
• profile.includedTestItems: List<RobotCodeTestItem> carries relSource and longname for each selected item.
• The top-level suite name is reachable via project.testManger.testItems (the workspace item's first child's longname).
• escapeRobotGlob(...) should be used for -I values (glob patterns), as in the discovery path.

Complication to investigate

The IntelliJ command is structured differently from VS Code's: it has no -- separator and no -d results. -N and -I are Robot options, so their placement/ordering relative to robotcode's own options (-bl) matters — a -- separator is very likely required so click does not mis-parse them. This needs to be worked out and verified.

Verification

Not covered by automated tests. Needs manual verification in the JetBrains sandbox IDE (./gradlew runIde) against a project that has a broken/incompatible .robot file next to a valid one, on RF ≥ 6.1:

• Run a single test → the executed command must contain -I <relpath> and -N <rootname>, and no parse errors from the unrelated file appear.
• Counter-check on RF < 6.1: no -I (the option does not exist there).

Context

• VS Code equivalent / background: [Bug] New version of RobotCode 2.6.* misses option -I in terminal command which causes errors #624