Maintenance loop spins with no delay when cleanup fails

I was reading through the db maintenance code and I think there's a problem with the loop when the cleanup step fails.

In `entrypoint` the loop just keeps calling `step()`:

```rust
while self.is_active() {
if let Err(e) = self.step().await {
error!("Database maintenance error: {e}");
}
}
```

And `step()` does the cleanup first and only sleeps at the very end:

```rust
let deleted = self.database.cleanup_old_notes(self.config.retention_days).await?;
info!(...);
timer.finish("ok");
sleep(Duration::from_secs(600)).await;
```

The sleep is the last line, after the `?`. So if `cleanup_old_notes` returns an error (db locked, disk full, corrupt file, etc.), `step()` returns early and the sleep never runs. The loop just logs the error and calls `step()` again straight away.

If the error keeps happening this becomes a tight loop with no wait between tries. It pins the CPU and floods the logs, which is extra bad when the disk is already full.

I think the sleep should run between every iteration, even when cleanup fails. The simplest fix is to move the interval sleep into the loop in `entrypoint` so it always runs. (Small extra thing: on the error path the `timer` is also dropped without calling `finish`.)

Code: [maintenance.rs](https://github.com/0xMiden/note-transport-service/blob/main/crates/node/src/database/maintenance.rs#L35-L59)

Happy to work on this if you can assign it to me.

The issue is in crates/node/src/database/maintenance.rs. Look at the entrypoint loop and the step method. The sleep should be moved to always execute, even after an error. Start by reading the linked code lines 35-59, understand the flow, and ensure the timer is properly handled on error paths. A test run of the maintenance loop would verify the fix prevents a tight loop.

Vom Indexierungsmodell aus dem Issue-Text verfasst.