LuCLI: auto-detect binary name from `ProcessHandle` instead of requiring `-Dlucli.binary.name`

[bpamiri]

Problem

The wheels CLI wrapper has to invoke LuCLI with -Dlucli.binary.name=wheels so CliProfile.forBinaryName() picks WheelsProfile. Without the explicit system property, LuCLI can't distinguish between being invoked as wheels vs lucli and falls back to DefaultProfile.

Ideal behavior

LuCLI detects the invocation name from ProcessHandle.current().info().command() (Java 9+) at startup and auto-selects the matching profile. Users can install both wheels and lucli as separate binaries/symlinks without each downstream installer needing a wrapper that passes the system property.

Current workaround

• Homebrew formula wrapper at ~/GitHub/wheels-dev/homebrew-wheels/Formula/wheels.rb exports -Dlucli.binary.name=wheels explicitly.
• Chocolatey package (pending v2 re-release) will need the same.
• Manual JAR installers have to do it themselves.

Works today, but every distribution channel has to replicate the dance.

Fix (upstream LuCLI)

In CliProfile.forBinaryName(), fall back to ProcessHandle.current().info().command() (strip path, strip .bat/.sh/.cmd suffixes) when -Dlucli.binary.name system property is unset.

Upstream: bpamiri/LuCLI (issues disabled — tracking here). Source at ~/GitHub/bpamiri/LuCLI/, see src/main/java/org/lucee/lucli/cli/CliProfile.java.

Discovered during Phase 2b-CLI distribution work. Non-blocking; documented workaround works.

[bpamiri]

Moved to bpamiri/LuCLI#4 — LuCLI now accepts issues directly.