Test suite isn't isolated from the developer's LuCLI home: writes into ~/.lucli, fails in a clean home #25

Summary

The test suite isn't isolated from the developer's own LuCLI home. Two problems have the same cause:

1. mvn test writes into the real ~/.lucli. ModuleArgBindingTest installs its typedbind fixture into LucliPaths.resolve().modulesDir() (the real ~/.lucli/modules by default). It removes the folder afterwards, but Lucee's compiled classes for it, and for McpCommandTest's mcpfixture, stay in ~/.lucli/lucee-server/.../cfclasses. The run also updates the real home's Lucee context logs and felix-cache.
2. The suite fails in a clean home. With the test JVM's home pointed at an empty directory (mvn test -DargLine="-Duser.home=<empty dir>", LUCLI_HOME unset), these tests fail (17 = 12 failures + 5 errors; the same set on the branch with fix(home): REPL history and settings follow LUCLI_HOME #22 merged):

• cli.commands.McpCommandTest.declaredMarkerParameterIsNeverBoundFromATerminalPositional
• cli.commands.McpCommandTest.failedToolPreservesReportAndRestoresCaptureForNextCall
• cli.commands.McpCommandTest.falseHelpArgumentsDoNotHijackMcpToolCalls
• cli.commands.McpCommandTest.terminalInvocationNeverCarriesTheMcpMarker
• cli.commands.McpCommandTest.toolCallCapturesOutStreamIntoResponseBody
• cli.commands.McpCommandTest.toolsCallCarriesARuntimeOwnedMcpMarker
• cli.commands.McpCommandTest.toolsListExcludesBaseModuleInternals
• cli.commands.McpCommandTest.toolsListHonorsMcpHiddenToolsDeclaration
• cli.commands.McpCommandTest.toolsListUsesModuleDeclaredInputSchema
• cli.commands.ModuleArgBindingTest.clusteredRootFlagsAndAttachedValuesPreserveModuleTimeout
• cli.commands.ModuleArgBindingTest.enabledHelpFlagsStillShowModuleHelp
• cli.commands.ModuleArgBindingTest.falseHelpFlagsRunTheRequestedCommand
• cli.commands.ModuleArgBindingTest.moduleTimeoutValuesReachTheModuleInsteadOfTheRootParser
• cli.commands.ModuleArgBindingTest.namedArgBeatsPositional
• cli.commands.ModuleArgBindingTest.singlePositionalLeavesOptionalAtDefault
• cli.commands.ModuleArgBindingTest.timeoutBeforeTheModuleRemainsARootOption
• cli.commands.ModuleArgBindingTest.twoPositionalArgsBindToTypedParams

Cause

These tests install their fixture module into the test JVM's LuCLI home, then spawn dev-lucli.sh as a subprocess (ProcessBuilder) without passing that home. So the child resolves its own home from the account's user.home.

• With the default home, both sides are the real ~/.lucli: the tests pass, but they write into it.
• With an isolated test home, the two differ: the child can't find the fixture, and the tests fail.

Possible fix

Give each of these test classes a temporary LUCLI_HOME (e.g. a @TempDir), install the fixture there, and pass it to the child via pb.environment().put("LUCLI_HOME", …) (and/or -Dlucli.home). The suite then never touches the developer's home, and it passes in a clean one.

Tested on: wheels-dev/LuCLI wheels @ 8942048 (17 failures; the extra McpCommandTest cases are fork patches). Upstream has the same issue on main (cybersonic#144).