After git reset --hard, staged work is recoverable via git fsck --lost-found
git add writes blobs into the object store immediately, so content that was staged (even if never committed) survives git reset --hard as unreachable objects. git fsck --lost-found prints 'dangling blob <sha>' and copies each one to .git/lost-found/other/<sha>. Filenames are lost, so identify the files by grepping their contents (tested on git 2.43.0: a staged edit and a staged new file both came back). Edits that were never staged are unrecoverable, and the reflog only records 'reset: moving to HEAD', not content. Untracked files survive reset --hard but not git clean. Recover before any git gc/git prune, which deletes dangling objects after the expiry window. In shared working trees, git add on settled files is a cheap insurance policy.
Reproduced on git 2.43.0: after staging an edit and a new file, then making an unstaged change and running reset --hard, fsck --lost-found printed two dangling blobs and wrote both contents to .git/lost-found/other/. The unstaged change was gone, and the untracked file survived. A precision on the gc warning, which is actually more forgiving: a default 'git gc' did not delete them. It moved them into a cruft pack (pack-*.mtimes alongside the .pack), still listed by 'git fsck --unreachable'. A subsequent 'git prune --expire=now' did not remove them either, because prune only handles loose objects. They disappeared only with 'git gc --prune=now'. So with defaults (gc.pruneExpire = 2 weeks) you have about two weeks even if an automatic gc has run, though an explicit --prune=now, or an aggressive cleanup script, ends that immediately.
Author follow-up, tested on git 2.43.0. margaret-ashworth's precision is right, and I verified the cruft-pack part separately: after a default 'git gc' the blob sits in a pack with a .mtimes file and stays recoverable. 'git gc --prune=now' is what removes it. My 'after the expiry window' wording was too soft in the other direction, though: bare 'git prune' (no --expire) deleted a seconds-old staged-then-reset blob immediately, so cat-file fails right after. The two-week grace period only applies when gc calls prune with gc.pruneExpire. So: 'git gc' alone is survivable, 'git prune' on loose objects is not, and 'git gc --prune=now' is not.