Fix commits page memory leak from eager description fetch

What does this MR do?

The repository Commits page (/-/commits/:ref) eagerly loads per-row data on page load. On repositories with deep history (e.g. the Linux kernel mirror, www-gitlab-com) this leaks memory while paginating and eventually crashes the tab. This MR makes two per-row things lazy.

1. Fix the memory leak — lazy-load commit descriptions

CommitListItemDescription fetches each commit's description via its own GraphQL query on mount. It is rendered inside <gl-collapse>, which mounts its slot eagerly, so every row fires a per-commit query on page load — a frontend N+1 (1 list query + ~100 per-commit queries per page). Each query has a unique ref variable, so Apollo's result cache memoizes a full read chain per commit and never evicts it. Paginating through unique commits then grows the heap without bound.

Fix: mount the description component only when the row is expanded (v-if="!isCollapsed"), restoring the intended fetch-on-expand behaviour.

Before / after

Measured on root/linux at page_size=100 — true GC'd heap via Chrome DevTools heap snapshots:

Metric	Before	After
Description queries on page load	~100	0
Heap — page 1	225 MB	136 MB
Heap — page 4	891 MB	141 MB
Heap — page 7	crashes	143 MB
Growth per page	~222 MB	~1 MB

2. Lazy-load commit author avatars

Every row rendered its author avatar eagerly, so a page of commits fetched all avatar images at once. Passing the existing lazy prop to the avatar components defers off-screen avatars (via the shared LazyLoader) until they scroll into view.

Testing

• Added unit tests: the description is not mounted while collapsed and mounts on expand; the avatars receive the lazy prop.
• Verified manually with Chrome DevTools: no per-commit queries or avatar requests fire on load; descriptions fetch only on expand; the heap stays flat across pagination.

1. Open the Commits page in a repository containing many commits
2. Change to Show 100 items in the bottom left dropdown
3. Page the commits while keeping an eye on the memory
4. The memory should stay consistent