[Feature Request] Allow build-session agents to author Workspace Skills via the agent stub/CLI surface

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] Please do not modify this template :) and fill in all the required fields.

### 1. Is this request related to a challenge you're experiencing? Tell me about your story.

We maintain a library of skills on self-hosted Dify 1.17.0 that multiple agents share. The natural way to **author** those skills is inside a build/debug session: the agent has the sandbox, the CLI, and the domain context, so it can iterate on a skill's `SKILL.md` and support files with real feedback loops.

Here we hit an asymmetry in 1.17's two skill systems:

- **Agent config skills** (Soul `config_skills`) can be written from the agent side — `dify-agent config skills push` works in build-draft sessions via the agent stub API (`api/controllers/inner_api/plugin/agent_config.py` → `AgentConfigService.push`).
- **Workspace Skills** (the tenant-shared `Skill` / `SkillVersion` / `AgentSkillBinding` library, `api/services/skill_management_service.py`) are **console-only**: their editable draft file tree, publishing (immutable versions), and bindings are all managed from the web console. There is no agent-stub/CLI path to create or update a workspace skill draft.

So an agent that just co-developed a great skill in its sandbox can only `config skills push` it into **its own per-agent config**, and a human must then manually re-create the content in the console to share it via the workspace library. The module docstring confirms the intended split: *"Bound Agents read workspace Skills through agent_skill_bindings at runtime; the Skill lifecycle must not mutate Agent config_skills snapshots or drafts"* — but nothing flows the other way either.

### 2. Additional context or comments

Source references from the `1.17.0` tag. Runtime consumption is read-only by design (`SkillManagementService.list_runtime_agent_skills` reads `latest_published_version_id`), which we agree with — this request is only about the **authoring** direction.

Suggested shape: allow a build-session agent (or the CLI used from it) to create/update a **workspace skill draft** through the stub surface, while keeping publishing as an explicit console (human) action. That would nicely complement #39316 (global skill management): the workspace library added in 1.17 answers "where shared skills live", and this would answer "how agents can contribute to it".

### 3. Can you help us with this feature?

- [ ] I am interested in contributing to this feature.

Start with api/controllers/inner_api/plugin/agent_config.py and AgentConfigService.push, then trace workspace draft and publishing behavior in api/services/skill_management_service.py. Define the stub/CLI entry point for creating and updating workspace skill drafts, while keeping publishing a console-only action and avoiding mutations to agent config snapshots or drafts.

Written by the indexing model from the issue text.