workspace: no path to publish a locally-authored skill to the linked workspace

## Gap

A skill authored locally cannot be published to the linked workspace from the CLI.
`src/altimate/workspace/skill-sync.ts` is one-directional — it pulls workspace skills
into a managed root under the project and reconciles them against a manifest and
registry. It issues `GET` only.

**Corrected scope (was wrong when filed):** this issue originally said publishing needs
a workspace API that does not exist. That is not the case — the workspace side already
supports creating a skill, updating one, writing bundle files and deleting, plus
attaching skills to a workspace. The missing half is entirely in this client.

## Impact

Two reports from field testing, both from this one gap:

- A user creates a project and a skill locally, then looks for the skill in the
workspace and does not find it. Nothing indicates publishing is a separate step.
- Users cannot tell whether publishing from the CLI exists at all — no command to
discover, no message pointing anywhere else.

## What the client needs

- **A `kind` on the bundle from day one.** The pull manifest already generalises —
`ManifestSkill` is `{updatedAt, files: Record}`, with nothing
skill-specific in it. Building the push path skill-shaped means agents and commands
later need a second pipe.
- **Refuse non-UTF-8 bundle files at publish, naming the offending path.** Binary files
cannot round-trip today: the size check at `skill-sync.ts:825` catches the mismatch
after the utf8 re-encode and skips the whole skill, logging a warning and nothing
else. Without a publish-time check the upload succeeds and the skill silently
disappears from every *other* machine's pull — a failure whose symptom is nowhere
near its cause.
- **Never publish from `MANAGED_DIR`** (`.altimate-code/skill/_workspace`). It is
discovered by the same `{skill,skills}/**/SKILL.md` glob as the user's own skills —
deliberately, since that is how workspace skills load — so a naive "publish my
skills" re-uploads workspace-owned bundles.
- **Persist the skill's server id after a first publish**, so re-publishing updates in
place instead of creating a second bundle. Open question: frontmatter (portable,
but changes the file format and shows in diffs) vs. a local manifest (invisible, but
lost on re-clone).
- **Handle the name-conflict response** as "you already have a skill named X". Names
are unique per creator, so this is a real and reachable state, not an edge case.

## Related

- #1276 — two creators may both own a skill with the same name, and the loader picks
one arbitrarily. Publishing makes that reachable far more often.