link: the CLI workspace picker has no type-ahead and starts on the current workspace, so reaching the right row on a busy tenant is error-prone

[anandgupta42]

Summary

The altimate-code link picker has no type-ahead filter, and on an already-linked project the cursor starts on the currently linked row rather than on the "＋ Create a quick workspace … here" row. On a tenant with more than a handful of workspaces the user has to arrow through the whole list, and it is easy to land on the wrong workspace. During end-to-end tests of #1318 on 0.12.1 (tenant anandtest1, 15 workspaces by then) the tester rebound a project to two unrelated workspaces before reaching the intended row.

By contrast, the TUI's "Link this project to a workspace" palette action filters the list live as you type (verified in the same session: typing pin- narrowed the list to pin-1 / pin-2). The CLI picker and the TUI picker should behave the same.

Reproduction

1. Tenant with ten or more workspaces; project already linked.
2. ALTIMATE_WORKSPACE=1 altimate-code link.
3. The picker opens on the current workspace's row; typing letters does nothing; the create row is at the top of the list, several arrow presses away depending on sort order.

Recording: ~/demos/workspace-pilot/recordings/wc1-quick-workspace-when-linked.mp4 (the second link run shows the navigation needed to reach the create row).

Suggested fix

Reuse the TUI picker's filter in the CLI prompt (type to filter by name or id), put the two create rows in a fixed position, and print the id next to each name so two workspaces with the same name (quick-create names them after the folder, so link-1 existed twice) can be told apart.

[anandgupta42]

@sahrizvi assigning with the rest of the workspace-pilot findings. Low severity, but it caused a real mis-bind during testing (a project was pointed at two unrelated workspaces before reaching the create row). The TUI's link picker already filters as you type; matching that in the CLI picker would be enough.