feat(cli): add install-skills command

[bercianor]

Add a new top-level install-skills command to install official Flamingock skills into ./.agents/skills for the current project.

Accept -g/--global for future compatibility, but return a clear not-implemented message for now.

Use Java-native HTTP/ZIP/NIO APIs to download and extract the official skills archive without depending on external tools like git, curl, or wget.

Implement full per-skill replacement for official flamingock-* directories while preserving user-defined custom skill folders.

Harden failure handling with actionable user-facing errors, HTTP timeouts, zip-slip protection, and robust temporary-workspace cleanup.

[dieppa]

Very well structured, with separation of concerns, simple interfaces and components that interact with each other, and everything orchestrated in the SkillsInstallationPipeline, which makes the actual CLI operation simple and easy to understand and follow.

The only thing is that most of the components should be generic. Then the caller pass the specific parameters.

Most of the components(if not all) should be generic file utility components

[bercianor]

I updated the implementation following the direction you suggested, while keeping the refactor intentionally small and simple.

What changed:

• Generic low-level helpers were moved out of the skills package into more appropriate reusable areas (filesystem, http, archive).
• Install-skills-specific orchestration stayed in InstallSkillsCommand and SkillsInstallationPipeline.
• Hardcoded install-skills values were pushed upward to the composition level, mainly in the pipeline, instead of being embedded inside reusable helpers.
• The trivial mode resolver abstraction was removed.

Also:

• The install flow is now prepared to resolve explicit installation targets instead of assuming a single destination path.
• SkillsInstallationPipeline now supports applying one download/extract/enumerate pass to one or many resolved targets, which prepares the structure for the future --global flow without changing current behavior.

What stayed specific on purpose:

• InstallSkillsCommand
• SkillsInstallationPipeline
• the install-skills flow and user-facing behavior

[dieppa]

I like, just few comments to nail it:

• we can move the utilities(inside filesystem and http folders) to util folder. You can have the filesystem and http subfolder if you wish.
• I think the class InstallationTarget can be generic too, but it's not wrong if it stays as skill-specific class. But if so, name it with skill, like the others. Something like `SkillsInstallationTarget"