fix: eliminate layout shift on tools pages - #84

Please address the comments from this code review:

## Overall Comments
- In `ActivityContributionGraph`, the keyboard navigation moves by 7 cells on horizontal arrows (treating columns as weeks), which may feel inverted compared to the visual grid; consider aligning ArrowUp/Down/Left/Right movement to the actual row/column layout so keyboard users traverse the calendar predictably.
- The HTTP status mapping in `src/app/api/ytmusic/recent/route.ts` is string-based and non-exhaustive; consider switching on the `YTMusicStatus` union (e.g. a `switch` or helper with `never` handling) so adding new statuses cannot silently fall back to 200.

## Individual Comments

### Comment 1
<location path="src/components/landing/activity/contribution-graph.tsx" line_range="435-444" />
<code_context>
+	const activeCellIndex = focusedCellIndex ?? todayCellIndex
+
+	function handleGridKeyDown(event: React.KeyboardEvent) {
+		const totalCells = totalWeeks * 7
+		const moveByKey: Record<string, number> = {
+			ArrowRight: 7,
+			ArrowLeft: -7,
+			ArrowDown: 1,
+			ArrowUp: -1
+		}
+
+		let nextIndex: number
+		if (event.key === 'Home') {
+			nextIndex = 0
+		} else if (event.key === 'End') {
+			nextIndex = totalCells - 1
+		} else if (event.key in moveByKey) {
+			nextIndex = Math.min(
+				totalCells - 1,
+				Math.max(0, activeCellIndex + moveByKey[event.key])
+			)
+		} else {
+			return
+		}
+
+		event.preventDefault()
+		setFocusedCellIndex(nextIndex)
+		cellRefs.current.get(nextIndex)?.focus()
+	}
+
</code_context>
<issue_to_address>
**suggestion:** Keyboard navigation assumes a full `totalWeeks * 7` grid, which can desync from actual rendered cells.

Because `totalCells` is derived from `totalWeeks * 7`, navigation can target indices for which no button exists (e.g. weeks with leading/trailing blanks). In those cases `cellRefs.current.get(nextIndex)` is undefined while `tabIndex` still treats that index as focused, so keyboard focus has no real DOM target. Consider deriving bounds from `cellRefs.current.size` or the actual `weeks` data so keyboard navigation only lands on rendered cells.

Suggested implementation:

```typescript
	const activeCellIndex = focusedCellIndex ?? todayCellIndex

	function handleGridKeyDown(event: React.KeyboardEvent) {
		const totalCells = cellRefs.current.size

		if (totalCells === 0) return

		const moveByKey: Record<string, number> = {
			ArrowRight: 7,
			ArrowLeft: -7,
			ArrowDown: 1,
			ArrowUp: -1
		}

		let nextIndex: number

		if (event.key === 'Home') {
			nextIndex = 0
		} else if (event.key === 'End') {
			nextIndex = totalCells - 1
		} else if (event.key in moveByKey) {
			const currentIndex = Math.min(activeCellIndex, totalCells - 1)

			nextIndex = Math.min(
				totalCells - 1,
				Math.max(0, currentIndex + moveByKey[event.key])
			)
		} else {
			return
		}

		// Only move focus to indices that have a rendered cell
		if (!cellRefs.current.has(nextIndex)) {
			return
		}

		event.preventDefault()
		setFocusedCellIndex(nextIndex)
		cellRefs.current.get(nextIndex)?.focus()
	}

	const cellRefs = useRef<Map<number, HTMLButtonElement>>(new Map())
	const [focusedCellIndex, setFocusedCellIndex] = useState<number | null>(null)

	const todayCellIndex = useMemo(() => {
		const todayStr = new Date().toISOString().split('T')[0]
		for (let weekIndex = 0; weekIndex < weeks.length; weekIndex++) {
			const dayIndex = weeks[weekIndex].findIndex(
				day => day.date === todayStr
			)
			if (dayIndex !== -1) return weekIndex * 7 + dayIndex

```

If `totalWeeks` is now unused after this change, it can be safely removed to avoid dead code. Also ensure that any code creating `cellRefs` entries uses zero-based, contiguous indices so that `cellRefs.current.size` accurately reflects the highest valid index; if indices can be sparse, consider normalizing them or adjusting navigation to use an ordered list of valid keys instead of numeric ranges.
</issue_to_address>

### Comment 2
<location path="src/app/api/ytmusic/recent/route.ts" line_range="44-48" />
<code_context>
 	}
 }
+
+function getHttpStatus(status: string): number {
+	if (status === 'unauthorized') return 401
+	if (status === 'unconfigured') return 503
+	if (status === 'error') return 502
+	return 200
+}
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Using `string` instead of the `YTMusicStatus` type for `getHttpStatus` weakens type safety.

`status` comes from `YTMusicResult.status`, which is a discriminated union (`YTMusicStatus`). Accepting a plain `string` allows unsupported values to be passed without compile-time errors. Typing the parameter as `YTMusicStatus` (and using `assertNever` in the default case) would keep the mapping aligned with the domain model and prevent invalid statuses at the type level.

Suggested implementation:

```typescript
function getHttpStatus(status: YTMusicStatus): number {
	if (status === 'unauthorized') return 401
	if (status === 'unconfigured') return 503
	if (status === 'error') return 502
	if (status === 'ok') return 200

	return assertNever(status)
}

```

To fully implement this change, you will also need to:
1. Ensure `YTMusicStatus` is imported or available in this file (e.g., `import type { YTMusicStatus } from '...';`).
2. Ensure `assertNever` is imported from your shared utilities (e.g., `import { assertNever } from '...';`) or implement it if it does not yet exist:
   `export function assertNever(x: never): never { throw new Error(\`Unexpected value: \${x}\`) }`.
3. Confirm that `'ok'` (or the equivalent success status) is one of the union members of `YTMusicStatus`; adjust the success-case branch accordingly if your union uses a different literal for the successful state.
</issue_to_address>