Cover RESTORE in the explicit rocksdb_dir grant test

A RESTORE supplies a table definition under whoever is restoring, who need
not be the user the backup was taken from, and it arrives at
LoadingStrictnessLevel::SECONDARY_CREATE, which isLoadingFromExistingMetadata
does not include. So the new FILE source check applies to it exactly as it
does to a CREATE. That was true of the previous commit but only by reading the
predicate: no arm reached SECONDARY_CREATE.

The arm backs up an explicit-dir table as the admin, drops it, and has a user
holding READ ON FILE but not WRITE ON FILE restore it. The RESTORE is refused
with the privilege sentence naming the missing WRITE, leaves no table behind,
and succeeds once WRITE ON FILE is granted. Modelled on the equivalent arm in
04401_url_engine_s3_dispatch_engine_grant.sh, which pins the same half of the
same predicate for the URL engine.

Measured against the same tree without the check: the denial half flips to
NOT DENIED and the table is created anyway, so it is a live arm, while the
granted half passes on both binaries and is therefore a positive control
rather than a second denial assertion.