SqliteStore#clear raises after the cache disables itself

[gemshrine]

Bug

Fbe::Middleware::SqliteStore#clear raises when the store has disabled itself after it cannot open or recreate the database. perform intentionally returns an empty result while @disabled is set, but clear unconditionally calls @db.execute('VACUUM;') after perform returns. In the disabled state @db is nil.

Steps to reproduce

1. Construct a store while its parent directory is writable.
2. Before the first store operation, make the SQLite database unavailable, for example by filling the filesystem so both the initial schema creation and the recovery attempt fail.
3. Call read, which attempts to open the database and causes open! to disable the cache after both attempts fail.
4. Call clear on the same store.

Actual result

clear raises NoMethodError for nil.execute instead of respecting the disabled state. read, write, delete, and all use perform's disabled guard and return without touching a database connection.

Expected result

clear should handle a disabled store consistently with the other operations and avoid dereferencing a missing database connection. A disabled cache should not turn a cleanup call into a new application failure.

Evidence

lib/fbe/middleware/sqlite_store.rb: open! sets @disabled = true and returns nil after both init! attempts fail; perform then returns [] when disabled. clear calls perform and immediately runs @db.execute('VACUUM;') outside that guard, while @db remains nil.