Mark bundled plugin rows with a mountain in listings

[TheGreatAxios]

Summary

• Plugin and skill rows from bundled origin repo plugins carry a mountain marker in the slash popup and the plugins listing
• Rows from other origins carry their origin label instead, while built-in rows stay unmarked

Verification

• bun run check passes (lint, typecheck, build, guarded test suite: 7143 pass, 0 fail)
• Marker paint and format behavior is covered by unit tests for both surfaces

Fixes CL-6888

[linear-code]

CL-6888

[TheGreatAxios]

Audit: NEEDS-WORK (AGENTS.md no-emoji marker)

Finding: BUNDLED_PLUGIN_MARKER = "⛰" (U+26F0) violates AGENTS.md ("No emojis in code or docs"). Beyond the rule, terminal width tables disagree on whether U+26F0 measures 1 or 2 cells wide, and the "marked row formats to exactly the target width" test is self-consistent — it measures with the repo's own stringWidth — so it cannot catch a real-terminal misalignment. Fix: switch to the ASCII [bundled], consistent with the existing [user] / [project] / [path] origin labels. I will push this fix to this branch.

Confirmed (no change requested):

• getCommand → listing equivalence: getCommand and listCommands (src/tui/commands/registry.ts) resolve the winner with the same find-first-active scan over pluginCandidates, so the marked row in listings is the same command dispatch runs.
• Filtering is unaffected (the marker lives only in the label; match runs on id/keywords), and row-width accounting holds through stringWidth.

[TheGreatAxios]

Audit: NEEDS-WORK (AGENTS.md no-emoji marker)

Finding: BUNDLED_PLUGIN_MARKER = "⛰" (U+26F0) violates AGENTS.md ("No emojis in code or docs"). Beyond the rule, terminal width tables disagree on whether U+26F0 measures 1 or 2 cells wide, and the "marked row formats to exactly the target width" test is self-consistent — it measures with the repo's own stringWidth — so it cannot catch a real-terminal misalignment. Fix: switch to the ASCII [bundled], consistent with the existing [user] / [project] / [path] origin labels. I will push this fix to this branch.

Confirmed (no change requested):

• getCommand → listing equivalence: getCommand and listCommands (src/tui/commands/registry.ts) resolve the winner with the same find-first-active scan over pluginCandidates, so the marked row in listings is the same command dispatch runs.
• Filtering is unaffected (the marker lives only in the label; match runs on id/keywords), and row-width accounting holds through stringWidth.