fix: send real SCRIPT LOAD/EVAL/EVALSHA instead of the local cache

[jamesx-improving]

Summary

eval, evalsha, eval_ro, evalsha_ro and script_load never sent their
namesake commands to the server. They went through glide-core's client-side
Script container and invoke_script, which produced three distinct
user-visible defects. This PR dispatches real EVAL / EVALSHA / EVAL_RO /
EVALSHA_RO / SCRIPT LOAD over the wire, and adds the standard integer
key-count call form.

One root cause, three findings closed. This PR contains two breaking
changes — see below.

Issue link

Closes #213

Also closes two findings from the #216 Group 1 rows (R2-12, R2-13), which were
not filed separately because they share this root cause.

Features / Changes

The three findings

• R3-4 — KEYS/ARGV misassignment on the integer key-count form.
  eval(script, 1, "mykey", "myarg") — the form used by valkey-cli and every
  Valkey doc example — put the count in KEYS[1], shifted the real key into
  ARGV[1], and silently dropped everything after it. No error was raised.
• R2-12 — script_load never sent SCRIPT LOAD. It computed a SHA1 into a
  client-local container, so the server had never seen the script. The returned
  SHA was unusable by any other client or process, and script_exists(sha)
  returned false for a script that had just been "loaded".
• R2-13 — script_flush was silently undone. Because evalsha resolved
  through the client-side container, the next evalsha after a flush simply
  re-uploaded the script from the client and succeeded. Flushing the server
  cache had no observable effect.

Why wire dispatch instead of typed dispatch

RequestType::Eval, RequestType::EvalSha and RequestType::ScriptLoad have
enum values in glide-core but no get_command() arm, so typed
send_command fails outright with Couldn't fetch command type. To be precise:
this is 3 of the 5 methods. EVAL_RO and EVALSHA_RO do have arms
(glide-core request_type.rs:1291-1292) and would work with typed dispatch
today. All five are nonetheless routed through call to keep the family
uniform — a deliberate choice with a known cost, see Known cost below. The
rationale is recorded in a module comment so a future contributor can revert to
typed dispatch once glide-core gains the missing arms.

BREAKING: evalsha on a flushed/never-loaded SHA now raises

It raises Valkey::CommandError whose message contains NoScriptError —
not Valkey::NoScriptError. Callers must catch Valkey::CommandError.

Valkey::NoScriptError is defined at lib/valkey/errors.rb:24 but is never
raised anywhere in lib/. The FFI exposes only four coarse RequestErrorType
values (UNSPECIFIED / EXECABORT / TIMEOUT / DISCONNECT), so NOSCRIPT
arrives as UNSPECIFIED and maps to CommandError. Verified live against a
real server.

Mapping the specific error subclasses is a pre-existing gap out of scope for
this PR — it equally affects PermissionError, WrongTypeError and
OutOfMemoryError, and deserves its own issue. Flagging it here so the
behavior is not mistaken for a regression introduced by this change.

BREAKING (smaller): ambiguous argument shapes now raise

Previously silent misparses now raise ArgumentError:

• Non-Integer numeric key counts (Float, Rational) — eval(s, 2.0, "k1", "k2")
  used to reproduce the exact bug this PR fixes, with no error at all.
• More than two positional arrays.
• script_load with a non-String script.

This follows the issue's own principle: proceeding with a silently different
meaning is precisely the thing to avoid. Integer and Array are disjoint in
the first positional slot, so recognizing the integer form is a strict superset
— it cannot change the meaning of any call that already worked.

A regression found during review, and fixed

Being honest about this one. Because every scripting method now goes through
call, which always forwards route:, and Valkey::Pipeline#send_command did
not accept route:, pipelined { |p| p.script_load(...) } regressed from
returning [] to raising ArgumentError: wrong number of arguments (given 3, expected 1..2).

Fixed by adding route: nil to Pipeline#send_command. The keyword is
accepted and ignored, matching the approach in #218 — batch-level routing
is a real feature but needs one route for the whole pipeline (see FFI
BatchOptionsInfo.route_info), not per-command routes. That work is tracked
in #137 and is out of scope here.

As a bonus, this also fixes a pre-existing case: pipelined { |p| p.dbsize; p.info }
used to raise ArgumentError on baseline because ~14 admin commands in
server_commands.rb forward route: unconditionally into Pipeline#send_command.
Verified: it now returns [Integer, Hash] cleanly. Non-block MULTI also
benefits — eval inside multi { } no longer executes outside the transaction.

Scope note: eval-in-pipeline was already broken before this branch
(NoMethodError on build_command_args), so that part is not a regression —
only script_load was. An earlier revision of this PR raised ArgumentError
when a route was supplied; changed to align with #218 after confirming no test
depends on either behavior.

Known cost — reviewer's call

OpenTelemetry spans for all five scripting methods are now named
CustomCommand rather than e.g. EVAL_RO (measured, not assumed).
EVAL_RO / EVALSHA_RO could retain real span names via typed dispatch today;
they were left uniform with the rest of the family and this is documented
in-code. Happy to split them out if maintainers prefer accurate span names over
family uniformity.

Tension with #206 — flagging, not resolving

#206 proposes a Script class; this PR moves away from the client-side
container. These are not fundamentally in conflict — invoke_script is
retained as the FFI seam. But #206 needs to know:

• script_load no longer populates glide-core's scripts_container, so
  invoke_script's NOSCRIPT auto-reload path is now unreachable. A Script
  class must either call store_script itself, or be built on EVALSHA +
  SCRIPT LOAD fallback in Ruby.
• Bindings.drop_script, Bindings.store_script,
  Bindings.free_script_hash_buffer and Bindings::ScriptHashBuffer are now
  entirely unreferenced in lib/ (drop_script was already dead before this
  branch). This PR enlarges the dead FFI surface. Left in place deliberately,
  since Add Script interface (invokeScript / Script class) parity with other GLIDE clients #206 may want it.

Cluster: reasoned, not locally tested

Routing is preserved because redis-rs derives it from the wire command name via
Routable::command() reading arg_idx(0), and CustomCommand builds an empty
Cmd with args appended. So EVAL → ThirdArgAfterKeyCount (slot derived from
the key count this PR now sends correctly), EVAL_RO → replica-optional,
SCRIPT LOAD → AllNodes / AllSucceeded. Verified by reading glide-core
source. Actual cluster validation is deferred to CI — stating that plainly
rather than claiming coverage I don't have.

Files changed

File	Change
lib/valkey/commands/scripting_commands.rb	Wire dispatch for all five methods; new split_keys_and_args helper handling all three call shapes; module comment recording the typed-dispatch constraint
lib/valkey/pipeline.rb	send_command accepts route: (raises if non-nil) — fixes the regression above
test/lint/scripting_commands.rb	26 new tests
CHANGELOG.md	## Pending entry, including both breaking changes

Testing

Lint — bundle exec rubocop lib/valkey/commands/scripting_commands.rb lib/valkey/pipeline.rb test/lint/scripting_commands.rb → 0 offenses.

Standalone suite — CI=1 SKIP_TLS_TESTS=true VALKEY_PORT=6413 bundle exec rake test:standalone
against a dedicated Valkey 8.1.3 instance:

Run	Tests	Assertions	Failures
Baseline (pristine fb2fa46)	840	4187	0
With this change	866	4207	0
Repeat run	866	4195	0

test_cached_script_execution — the known pre-existing flake (#167 / #124) —
passed in both final runs.

The R2-12 / R2-13 tests assert real server state, not client-side echoes:

• test_script_load_makes_the_script_available_on_the_server
• test_script_loaded_by_one_client_is_usable_by_another — cross-client, which
  is what actually proves the SHA reached the server
• test_script_flush_really_invalidates_the_script — asserts the raise and
  re-asserts script_exists == false, proving no client-side re-upload
• test_evalsha_raises_for_a_never_loaded_sha

All new tests live in the shared lint module, so they run in both the
standalone and cluster suites.

Deferred: bundle exec rake test:cluster — to CI (see Cluster above).

Performance: the warm path drops from 3 round trips to 1.

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one issue.
• Commit message has a detailed description of what changed and why.
• Tests are added or updated.
• Documentation is updated (if applicable).
• Linters have been run (bundle exec rubocop) and pass.
• Destination branch is correct - main (destination here is release-1.0, per the 1.0.0 GA release-blocker track)

[Aryex]

I think the issue here is that GLIDE clients does support custom script executions often through the Script class implementation, which the current Ruby client does not implement.

[Aryex]

AI tends to just spits out large comments blocks. I think we could remove this and instead add a TODO to #206

[jamesx-improving]

Done in 1d7aade — dropped the module-level block. I'll leave a TODO on #206 capturing the "revert to typed dispatch once glide-core has get_command() arms" context so it's not lost. Good call — you're right that it belonged there rather than as a header on the file.