dolt log --oneline hangs after fsck --revive-journal-with-data-loss on recovered repo

# Summary

After recovering a corrupted local Dolt repository with `dolt fsck --revive-journal-with-data-loss`, the repository becomes usable again for normal operations, but `dolt log --oneline` does not recover cleanly.

In the recovered state:
- `dolt status` works
- `dolt sql -q 'show tables'` works
- SQL access to `dolt_log` works
- but `dolt log --oneline` prints `no commits found for ref ...` and then hangs until killed / timed out

This seems like a distinct post-recovery state problem: the database is partially usable, but local log traversal is still broken.

# Environment

- Dolt version: `1.83.1`
- OS: Linux
- Deployment shape: local repository plus `dolt sql-server`
- Note: I have not yet reproduced this on the latest Dolt release

# What happened

The repository first entered a corrupted journal state. The local repo failed to open cleanly and emitted:

```text
possible data loss detected in journal file at offset 40446034: corrupted journal
please run 'dolt fsck' to assess the damage and attempt repairs
```

Running:

```bash
dolt fsck --quiet
```

returned:

```text
WARNING: Chunk journal is corrupted and some data may be lost.
Run `dolt fsck --revive-journal-with-data-loss` to attempt to recover the journal by
discarding invalid data blocks. Your original data will be preserved in a backup file.
```

Running:

```bash
dolt fsck --revive-journal-with-data-loss
```

completed successfully and created a `_save_...` backup of the original journal.

# Post-recovery behavior

After the revive step:

## These commands succeed

```bash
dolt status
```

```bash
dolt sql -q 'show tables'
```

and, through the running server:

```bash
dolt --host 127.0.0.1 --port --user root --password "" --no-tls sql -q 'USE ; SELECT COUNT(*) AS count FROM dolt_log'
```

That last query returns a valid count quickly.

## This command fails strangely

```bash
timeout 5s dolt log --oneline
```

Output:

```text
no commits found for ref erc3bdihlr9dh3obqohp1v0g85krl5in
```

Exit status after timeout:

```text
124
```

So `dolt log --oneline` does not fail fast. It emits the missing-ref message and then remains stuck until killed.

# Expected behavior

After `dolt fsck --revive-journal-with-data-loss`, one of these should happen:

1. `dolt log --oneline` should work on the recovered repository, or
2. it should fail immediately with a clear error describing the remaining inconsistency

It should not hang indefinitely after printing an error.

# Actual behavior

The recovered repository is usable for status / SQL access, but `dolt log --oneline` appears to walk into an inconsistent commit graph state and hangs.

# Why this matters

This broke a health-report path that used local `dolt log --oneline | wc -l` as a lightweight commit-count probe. I worked around that locally by switching the probe to:

```sql
SELECT COUNT(*) FROM dolt_log
```

but the underlying `dolt log` behavior still looks buggy and worth fixing upstream.

# Minimal reproduction outline

I do not currently have a synthetic reproducer for the original journal corruption, but the observed sequence was:

1. local repo enters corrupted-journal state
2. `dolt fsck --revive-journal-with-data-loss` succeeds
3. repo becomes usable for status / SQL again
4. `dolt log --oneline` still emits `no commits found for ref ...` and hangs

If useful, I can provide more of the exact command/output transcript from the recovered repo state.

Start by reproducing the sequence with `dolt fsck --revive-journal-with-data-loss`, then compare `dolt log --oneline` with `SELECT COUNT(*) FROM dolt_log` on the recovered repository. Capture the missing ref and timeout behavior; done means log traversal either succeeds or exits promptly with a clear inconsistency error.

Written by the indexing model from the issue text.