`BazaRb::Fake#durable_place` and `#durable_save` crash with TypeError on a nil file, instead of matching `BazaRb`'s RuntimeError

[gemshrine]

Steps to reproduce

require "baza-rb"
require "baza-rb/fake"

real = BazaRb.new("example.org", 443, "token")
fake = BazaRb::Fake.new

real.durable_place("valid-pname", nil)

and

fake.durable_place("valid-pname", nil)

Actual result

real.durable_place("valid-pname", nil) => RuntimeError: The "file" of the durable is nil
fake.durable_place("valid-pname", nil) => TypeError: no implicit conversion of nil into String

The same divergence happens for durable_save:

real.durable_save(42, nil) => RuntimeError: The "file" of the durable is nil
fake.durable_save(42, nil) => TypeError: no implicit conversion of nil into String

Expected result

BazaRb::Fake is documented to implement the same public interface and validation as BazaRb. Both durable_place and durable_save should raise a clean RuntimeError with a message about the missing file, the same way the real client does, instead of an unrelated TypeError.

Cause

BazaRb::Fake#durable_place and #durable_save both call the private checkfile(file) helper, which goes straight to File.exist?(file) without checking file.nil? first. File.exist?(nil) raises TypeError: no implicit conversion of nil into String before checkfile gets a chance to raise its own error. The real BazaRb#durable_place/#durable_save both explicitly check raise(RuntimeError, ...) if file.nil? before touching the filesystem, so they never hit this path.

This is the same class of problem as the already-fixed checkname nil crash (issue #447), just in checkfile instead.

Proposed fix

Add a file.nil? check at the top of Fake#checkfile, raising the same RuntimeError message the real client uses, before calling File.exist?.