#2236: preserve working directory when launching VS Code

[cap-juan]

This PR fixes #2236

Implemented changes:

• Changed the VS Code launch path to use the current working directory instead of the IDEasy workspace root.
• This preserves the directory from which ide vscode was invoked.
• Newly opened VS Code integrated terminals now start in the same directory.
• Existing workspace configuration and VS Code metadata handling remain unchanged.

---

Testing instructions

Please add conscise, understandable instructions on how a reviewer can test/verify the functionality of your contribution here:

1. Build the native CLI: mvn -B -ntp -pl cli -am -Pnative package -DskipTests

2. From Git Bash, navigate to a subdirectory, e.g.: cd ~/Projects/IDEasy/workspaces/main/IDEasy/cli

3. Launch the freshly built IDEasy executable: ./target/ideasy.exe vscode

4. Verify that VS Code opens the current directory.

5. Open a new integrated terminal in VS Code and run: pwd

6. Verify that the terminal starts in the same directory from which ide vscode was launched.

---

Checklist for this PR

Make sure everything is checked before merging this PR. For further info please also see
our DoD.

• When running mvn clean test locally all tests pass and build is successful
• PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat and not feature/921 fixed setup.bat). If no issue ID exists, title only.
• PR top-level comment summaries what has been done and contains link to addressed issue(s)
• PR and issue(s) have suitable labels
• Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
• You followed all coding conventions
• You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labelled
  with internal
• You have not changed any dependency in pom.xml files or otherwise if runtime dependencies changed, you have updated our LICENSE.asciidoc
• You have formulated clear instructions on how to test your contribution under "Testing instructions"

Checklist for tool commandlets

Have you added a new «tool» as commandlet? There are the following additional checks:

• The tool can be installed automatically (during setup via settings) or via the commandlet call
• The tool is isolated in its IDEasy project, see Sandbox Principle
• The new tool is added to the table of tools in LICENSE.asciidoc
• The new commandlet is a command-wrapper for «tool»
• Proper help texts for all supported languages are added here
• The new commandlet installs potential dependencies automatically
• The variables «TOOL»_VERSION and «TOOL»_EDITION are honored by your commandlet
• The new commandlet is tested on all platforms it is available for or tested on all platforms that are in scope of the linked issue

[coveralls]

Coverage Report for CI Build 34487872012

Coverage increased (+0.004%) to 73.908%

Details

• Coverage increased (+0.004%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	18801
Covered Lines:	14523
Line Coverage:	77.25%
Relevant Branches:	8403
Covered Branches:	5583
Branch Coverage:	66.44%
Branches in Coverage %:	Yes
Coverage Strength:	3.29 hits per line

---

💛 - Coveralls

[JoelAdbu]

Well Done!

[hohwille]

I understood issue #2393 and its kind of duplicate #2236 such that people wanted to open a separate git repo like settings in VSCode (or an other IDE of their choice).
However, IDEasy has an explicit feature that I do not have to explicitly do cd workspaces/main every time before I run my IDE since main is defined as the default workspace to open.
Therefore, if I am in $IDE_HOME or $IDE_HOME/workspaces I do not want to change the current behaviour and opening the entire project or workspaces folder is not what I personally would like to have.
Also I think that a lot of IDEasy users are used to this current behaviour and would get confused if that changes rather by accident.
Either we introduce an explicit option to open the current working directory regardless of what the derived workspace folder would be or we should only do this tweak if we are in an subfolder of my project unrelated to workspaces like settings what this feature was IMHO originally requested for.
BTW: Usually the idea is to first do a clarification of the story, then set the ready-to-implement label and then start a PR. Since we are already in that refinement now, I would also add that Eclipse has a totally different philosophy of a "workspace" that is totally unrelated to working directories since you can import any project from any location on your disc into the current workspace, so importing your settings folder can be done in any workspace of your choice like main or something else.
However, for IntelliJ or any JetBrains/IDEA based IDE the philosophy is similar to VSCode so maybe we want to change the behaviour for that in the same way to make it somehow more consistent.