feat(cases): add inline edit and delete actions

[Lint111]

Summary

• Add distinct edit and delete icon actions beside each desktop case-picker option.
• Add separate, touch-sized edit and delete actions to the mobile case picker.
• Reuse the existing case-settings popover and delete-confirmation flow.
• Preserve row selection as a separate action so editing or deleting cannot accidentally launch a case.

Motivation

Case maintenance was available only through the settings window even though users select cases from the quick-start picker throughout normal work. The extra navigation is especially costly on mobile.

Scope

This is the inline case-management slice extracted from #173. It includes the picker behavior, the exact desktop/mobile styles required by the new controls, and focused tests. It does not change case APIs or deletion semantics.

Interaction details

• Desktop actions appear when a row is hovered or contains keyboard focus.
• Mobile keeps the case-selection target at least 44px high and places the two actions at the row edge.
• Delete continues to require the existing user confirmation.

Validation

• npx vitest run --config config/vitest.config.ts test/run-mode-ui.test.ts: 15 passed
• Temporary Playwright probe: 6 mobile action buttons and 2 desktop action buttons visible; all mobile controls remained inside a 390px viewport
• npm run check:frontend-syntax: 26 files passed
• npm run build: passed
• Commit formatting hook: passed
• git diff --check: passed

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Ark0N]

Thanks for splitting this out of #173. The idea is good, inline case actions are genuinely useful, and restructuring the mobile row so the case name and the destructive action are separate tap targets is the right shape.

I'm not merging it yet though. I built the branch merged onto current master, ran it in an isolated beta instance and drove it in a real browser (desktop 1440px and phone 390px, dark and light skins). The happy path does work end to end: I created a throwaway case, deleted it through the new inline trash button, and confirmed the dialog, the DELETE /api/cases call, the toast, the picker refresh and the folder removal on disk all behaved. But there are enough problems that it needs another pass.

Blocking

1. The desktop actions can't be reached by keyboard. The PR description says they appear "when a row is hovered or contains keyboard focus", but keyboard focus can never land there. setupQuickStartCasePicker() treats Tab on the search input as "close the picker", and the list has mousedown -> preventDefault(), so the buttons never receive focus by either route. I measured it: Tab from #quickStartCaseSearch moves straight to btn-case-add with the list already hidden. That makes the :focus-within and :focus-visible rules dead code, and the whole feature mouse-only.

2. role="listbox" now contains 46 non-option buttons. Every option got wrapped in a bare <div class="case-combobox-row"> with no role, so the role="option" elements are no longer children of the listbox, and the two action buttons are invalid listbox descendants. role="presentation" on the row wrapper fixes the first half.

3. Both light skins break..case-combobox-action hardcodes background: #242a34, so on paper-gray / solarized-light / catppuccin-latte / rose-pine-dawn you get dark navy chips floating in a white popup, with the icon at roughly 2.5:1 contrast against its own button. On mobile it's the opposite failure: rgba(255, 255, 255, 0.04) on rgba(255, 255, 255, 0.1) over a white sheet leaves the buttons with no visible chrome at all. Measured on the running instance: desktop list background rgba(255, 255, 255, 0.97) vs action background rgb(36, 42, 52). Please use the skin tokens (--control-bg, --control-border) instead of literals. docs/architecture-invariants.md#theme-skins covers why the four light skins need explicit handling.

4. The row highlight flickers when you reach for the buttons. The actions are absolutely positioned siblings of the option, so hovering one drops .case-combobox-option:hover and the row's highlight disappears right as the cursor arrives. Measured rgba(59, 130, 246, 0.16) -> rgba(0, 0, 0, 0). A .case-combobox-row:hover .case-combobox-option rule fixes it.

Worth fixing

5. Mobile action buttons are 36x36. The selection target does hit the 44px you promised, but the two actions don't, and delete sits 8px from the screen edge, 4px from edit. That's a mis-tap risk on a destructive action.

6. The pencil over-promises. It opens the existing two-checkbox popover (Agent Teams, 1M Opus Context). A pencil next to a case name reads as rename / path / location editing, so this will surprise people. Either use a gear and call it "Case options", or point it at the real case management UI.

7. Smaller things.padding: 0.35rem 4.2rem 0.35rem 0.45rem reserves the action strip permanently, so labels truncate earlier even while the buttons are hidden. The new title and aria-label strings are hardcoded English. The render test's toHaveLength(3) for two cases quietly depends on the synthetic testcase entry, which will read as a bug to the next person to touch it. And nothing covers the delegated click handler or the mobile render path.

One process request

You have 20 PRs open, 19 of them opened on the same day. I do read them properly, which means every one costs a full review cycle: build, isolated instance, real browser, both viewports, all the skins. Several of the issues above would have surfaced in one pass of the feature in a browser with a light skin selected and a Tab press, so please put the branch through that yourself before opening the next batch. Fewer, more finished PRs land much faster here than many rough ones.

Happy to take this again once the blocking items are addressed.

[Ark0N]

Hi Lior, closing this one as part of a cleanup of the seventeen PRs currently open from you. The full explanation is in #173, and I would rather you read that one than this note, because it is the honest version and it is not a dismissal of your work.

The short form: sixteen PRs opened in a single day, roughly 42,000 added lines in total, landing mostly on the same few files (nine touch app.js, eight touch terminal-ui.js), with five already conflicting against master and none carrying CI results. I cannot review that at the standard this codebase needs, and merging it at a lower standard would be worse than not merging it.

Going forward, please keep no more than three open PRs at a time, each one a single behavior change that stands on its own, with a test that fails on master and passes with the fix. #214 and #215, merged today, are good models.

If this particular change fixes something that genuinely annoys you in daily use, it is a good candidate to be the first one you reopen on its own, rebased on current master. I will review it properly.

Thanks for the effort you put in, and sorry to close it this way.