skip terminal grid sizing when available width is non-positive

[thedhruvhegde]

summary

computeGridDimensions already bailed on availH <= 0 but not width. a collapsed pane could still produce a bogus column count.

return null when availW <= 0 as well.

test plan

• collapse a pane so the terminal has no usable width and confirm no throw / zero-col resize
• pnpm --dir apps/emdash-desktop exec vitest run src/core/features/terminals/browser/pty/pty-dimensions.test.ts

[greptile-apps]

Greptile Summary

This PR prevents terminal grid sizing when horizontal padding and scrollbar space leave no usable width.

• Adds a symmetric non-positive-width guard alongside the existing height guard.
• Adds focused unit coverage for negative available width.
• No security concerns were identified.

Confidence Score: 4/5

The implementation appears safe to merge, with a non-blocking test-coverage gap at the exact-zero width boundary.

The production guard is consistent with existing height handling and its callers safely handle null; only the precise availW === 0 regression boundary remains untested.

Files Needing Attention: apps/emdash-desktop/src/core/features/terminals/browser/pty/pty-dimensions.test.ts

Important Files Changed

Filename	Overview
apps/emdash-desktop/src/core/features/terminals/api/browser/pty/pty-dimensions.ts	Correctly returns null for non-positive available width, using an established contract already handled by callers.
apps/emdash-desktop/src/core/features/terminals/browser/pty/pty-dimensions.test.ts	Covers negative available width but omits the exact-zero boundary introduced by the new condition.

Prompt To Fix All With AI

### Issue 1
apps/emdash-desktop/src/core/features/terminals/browser/pty/pty-dimensions.test.ts:43-49
**Zero width remains untested**

This fixture produces `availW = -12` (`4 - 8 - 8`), so it only tests negative available width. The changed contract also covers `availW === 0`; without an exact-zero case, changing the guard from `<= 0` to `< 0` would still pass this test and leave the boundary behavior unprotected.

```suggestion
      computeGridDimensions({
        widthPx: 16,
        heightPx: 400,
        cellWidth: 8,
        cellHeight: 16,
        paddingPx: 8,
      })
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "treat non-positive available width the s..." | Re-trigger Greptile}

[greptile-apps]

Zero width remains untested

This fixture produces availW = -12 (4 - 8 - 8), so it only tests negative available width. The changed contract also covers availW === 0; without an exact-zero case, changing the guard from <= 0 to < 0 would still pass this test and leave the boundary behavior unprotected.

Suggested change

	computeGridDimensions({
	widthPx: 4,
	heightPx: 400,
	cellWidth: 8,
	cellHeight: 16,
	paddingPx: 8,
	})
	computeGridDimensions({
	widthPx: 16,
	heightPx: 400,
	cellWidth: 8,
	cellHeight: 16,
	paddingPx: 8,
	})

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/emdash-desktop/src/core/features/terminals/browser/pty/pty-dimensions.test.ts
Line: 43-49

Comment:
**Zero width remains untested**

This fixture produces `availW = -12` (`4 - 8 - 8`), so it only tests negative available width. The changed contract also covers `availW === 0`; without an exact-zero case, changing the guard from `<= 0` to `< 0` would still pass this test and leave the boundary behavior unprotected.

```suggestion
      computeGridDimensions({
        widthPx: 16,
        heightPx: 400,
        cellWidth: 8,
        cellHeight: 16,
        paddingPx: 8,
      })
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!