feat(jetbrains): import JetBrains support from Kilo-Org/kilocode#2129 (JetBrains-only)

[daniel-lxs]

Pulls JetBrains support from downstream PR https://github.com/Kilo-Org/kilocode/pull/2129.\n\nIncluded:\n- jetbrains/**\n- deps/patches/vscode/jetbrains.patch\n\nExcluded: all unrelated changes. Removed any LFS pointer artifacts (e.g., platform.zip). Applied via git checkout from kilocode PR to avoid manual edits.

[ellipsis-dev]

⚠️ This PR is too big for Ellipsis, but support for larger PRs is coming soon. If you want us to prioritize this feature, let us know at [email protected]

---

Generated with ❤️ by ellipsis.dev

[roomote]

Post-Closure Review Summary

Thank you for the effort to import JetBrains support from the downstream fork. While this PR is now closed, I wanted to document some observations for future reference when this feature is re-attempted:

Critical Issues Found

1. Temporary files in repository: The tmp/ directory contains files that appear to be temporary artifacts:

   • tmp/jetbrains-only.patch (63,625+ lines)
   • tmp/kilocode-2129 (submodule reference)
   • tmp/pr-2129-files.txt

   These should be excluded from the final implementation.

2. Binary file concerns: jetbrains/plugin/platform.zip is included despite the mention of removing LFS pointer artifacts. Consider whether this should be generated during build rather than committed.

3. Large VSCode patch: The deps/patches/vscode/jetbrains.patch file with 1,832 additions is substantial and would benefit from documentation explaining what VSCode modifications are necessary and why.

Architecture Considerations

4. Build system complexity: The addition of multiple build systems (Gradle for Kotlin, TypeScript compilation) increases maintenance overhead. Consider documenting the build pipeline clearly.

5. Dependency management: The integration introduces both Node.js and Java/Gradle dependencies. Future implementations should ensure these are well-documented and compatible with existing CI/CD pipelines.

6. Code organization: There appear to be duplicate files (multiple bootstrap files, duplicate theme CSS). Consider consolidating these for maintainability.

Suggestions for Future Implementation

• Add comprehensive documentation explaining the JetBrains integration architecture
• Provide Windows equivalents for shell scripts (currently only gradlew.bat is included)
• Consider breaking this into smaller, reviewable PRs (e.g., infrastructure first, then features)
• Ensure all temporary and generated files are properly gitignored

This feedback is provided for when JetBrains support is revisited. The modular approach of keeping JetBrains-specific code in its own directory is good for maintainability.