Startup scan: warn (don't silently skip) when the reserved `restore` metadata dir looks like a database

Follow-up from #1831 review (flagged by @kriszyp on `resources/databases.ts`).

## Context
#1831 stores restore lock/marker metadata in a reserved ``restore`` directory beside the database directories. The backtick makes it an illegal database name (`schemaRegex` rejects `/` and backtick), so the API can never create a database that collides with it, and the startup scan explicitly skips that entry.

## Edge case
The startup scan opens any directory containing `CURRENT` + `MANIFEST-*` **without re-applying `schemaRegex`**. So if a directory literally named ``restore`` already exists on disk as a RocksDB database (only reachable via manual filesystem creation, since the API always rejected backticks), an upgrade to this code now **silently stops loading that database**, and a subsequent restore would write `.lock`/`.restoring` metadata into it.

## Severity
Very low probability (no API path can produce such a directory), but the silent disappearance is a bad state to hit undiagnosed.

## Suggested fix
When the scan skips the reserved ``restore`` entry, detect whether it looks like a real database (has `CURRENT` + `MANIFEST-*`) and **log a warning** (or refuse startup with a clear message) rather than silently ignoring it, so an operator can migrate/rename it.

Ref: #1831, `resources/databases.ts` scan loops.

Start in resources/databases.ts at the startup scan loops and review how the reserved restore entry is skipped. Check the entry for CURRENT and MANIFEST-* before it is ignored, then warn or fail clearly when it looks like a database. Done means a conflicting restore directory is no longer silently skipped and normal startup scanning still works.

Written by the indexing model from the issue text.