feat(projects): auto-translate raw unicode emoji to shortcode for --icon

[flipbit03]

Background

Surfaced as follow-up #1 in #146 (and PR #147 lands the doc fix that's the immediate-scope half of that issue).

Linear's API rejects raw unicode emoji on icon fields (🔁, ⭐, 📦 → INVALID_INPUT) but accepts the equivalent colon-wrapped shortcode (:repeat:, :star:, :package:). #146 documents this; this issue tracks making lineark paper over the gap so users don't have to know.

Proposal

When --icon receives a value containing non-ASCII chars, translate it to its standard emoji shortcode before sending to Linear. So:

lineark projects create "Demo" --team ENG --icon "🔁"
# lineark internally rewrites to --icon ":repeat:" and the API accepts it

The standard emoji↔shortcode mapping is well-defined and shared across Slack, GitHub, Discord, and emojibase — picking any one of those tables (or the emojis crate, which exposes Slack/GitHub shortcodes from a generated table) gets us coverage of the common set.

Behavior

• Input is pure ASCII → pass through unchanged (named icons, existing shortcodes).
• Input contains a recognized unicode emoji → rewrite to :shortcode: and proceed.
• Input contains an unrecognized non-ASCII char → pass through unchanged; let Linear reject it. Rationale: don't silently discard data we don't understand.

Escape hatch

--icon-raw (or --no-translate) for users who genuinely want to send raw bytes — useful if Linear ever fixes the validator and we need a way to test without lineark "helping."

Scope

• In scope: projects create, projects update (the two paths docs(projects): --icon help text claims emoji are accepted but Linear API rejects them #146 fixed the help text on).
• Out of scope (separate issues): apply the same translation to other entities with icon fields (teams, custom views, dashboards, documents, project templates) — only after each is verified to behave the same way at the API.

Why this isn't speculative

• The format matrix is already verified in docs(projects): --icon help text claims emoji are accepted but Linear API rejects them #146.
• A standard emoji→shortcode mapping is a known-quantity dependency.
• Two-line CLI surface change. No SDK changes — translation happens in the CLI command handlers (or a small helper next to parse_priority/resolve_*).
• The doc-fix in docs(projects): --icon help text claims emoji are accepted but Linear API rejects them #146 / PR docs(projects): warn that Linear's API rejects emoji for --icon #147 stays useful: even after this lands, the :repeat: form remains a valid input format, and the named-icon form remains the discoverable-without-shortcode-knowledge form. The new help text would just stop saying "rejects raw unicode emoji."

Acceptance criteria

• --icon "🔁" translates to :repeat: and succeeds against Linear's API
• --icon "Computer" (named icon) passes through unchanged
• --icon ":repeat:" (already-shortcode) passes through unchanged
• --icon "<unrecognized unicode>" passes through unchanged and surfaces Linear's rejection
• Online test in crates/lineark/tests/online.rs covers the unicode→shortcode happy path against a real project
• Offline test covers the translation logic in isolation
• --icon help text updated to remove the "rejects raw unicode emoji" warning (since lineark now handles it)

[flipbit03]

Closing as YAGNI.

PR #147 already updates the --icon help on both projects create and projects update to direct users at shortcodes (:repeat:) and named icons (Computer), with an explicit "raw unicode rejected" warning. Once a user reads the help (or hits the API error and pivots), the path forward is obvious — saving a 30-second pivot doesn't justify a new dependency, translation logic with edge cases (skin tones, ZWJ sequences, flags), an --icon-raw escape hatch, and a new silent-rewrite failure mode if Linear ever changes behavior.

Reopen if there's a real user/LLM consumer hitting this repeatedly despite the updated help text — that would be evidence the docs aren't enough.