fix: dragonsmouth-from-slot '*' falls back to gRPC slot on empty blocks_metadata

[gamandeepsingh]

Problem

DRAGONSMOUTH_FROM_SLOT="*" hard-errors on a fresh deployment where
blocks_metadata has zero rows:

Error: dragonsmouth-from-slot '*' requires at least one row in default.blocks_metadata

This contradicts the documented fallback in crates/superbank/README.md:

dragonsmouth-from-slot: "*" uses the highest slot in blocks_metadata
before subscribing; if rejected, superbank falls back to the
gRPC-reported available slot.

That fallback does work when a resolved slot turns out to be stale/
unavailable (superbank logs slot not available; falling back to gRPC available slot and recovers). It just never gets a chance to run when
the table is empty in the first place, since resolve_initial_from_slot
(crates/superbank/src/ingest/grpc.rs) errors out before reaching
that path.

Fix

resolve_initial_from_slot's FromSlotSpec::LatestDb branch now
matches on fetch_latest_slot_from_blocks's result instead of using
.ok_or_else to hard-error on None:

• Some(latest) — unchanged, resolves to that slot as before.
• None (empty table) — resolves to (None, FromSlotMode::LatestDb)
  instead of erroring. With no from_slot set on the initial subscribe
  request, gRPC starts the stream from its own current slot, which is
  the same "gRPC-reported available slot" outcome the stale-slot case
  already falls back to.

Updated crates/superbank/README.md to document the empty-table case
explicitly.

Test plan

• cargo fmt --all -- --check
• cargo clippy -p superbank --all-targets --locked -- -D warnings
• cargo test -p superbank --locked (56 passed)

Fixes #56