Name-taking BazaRb methods leak NoMethodError for non-String names

[gemshrine]

Symptom and impact

The public methods that accept a job or product name check for nil, emptiness, allowed characters, and length, but they do not first check that the value is a String. Passing another type therefore raises a raw NoMethodError from a String method instead of the client’s documented validation error. The fake client has the same gap, so tests using it cannot receive a clear type error either.

Reproduction

client = BazaRb.new('example.org', 443, 'token')
client.name_exists?(42)

The real client raises NoMethodError for Integer#empty?. The fake path fails too:

BazaRb::Fake.new.name_exists?(42)

Fake#checkname calls match? on the integer and raises NoMethodError there.

Actual result

Invalid input escapes as an implementation-level NoMethodError, with no indication that the name must be a string. The same validation pattern is used by lock, unlock, recent, durable_find, durable_place, and enter.

Expected result

The real and fake clients should reject non-string names with a clear RuntimeError, consistently with their existing checks for nil, empty, malformed, and overly long names.

Technical evidence

In lib/baza-rb.rb, methods such as name_exists? call pname.empty? before any type check. In lib/baza-rb/fake.rb, checkname calls name.match? without checking the type. The edge tests cover malformed string names but do not cover non-string names.