fix: bump bandit for two CVEs, pick up the released bb 0.30 chain, and stop reporting :homed for a move that didn't happen

[jimsynz]

Three independent commits, each standing on its own.

1. bandit 1.12.5 — EEF-CVE-2026-75484, EEF-CVE-2026-74836

Both advisories are against bandit 1.12.4, which this lockfile pinned. 1.12.5
shipped 2026-08-20 and the ~> 1.5 requirement already admits it, so the
lockfile is the whole change — one line, nothing else moved.

This is not a dev-only dependency here, which is worth knowing before
ranking the bump. {:bandit, "~> 1.5"} carries no only:, and
config/config.exs sets adapter: Bandit.PhoenixAdapter at base config rather
than in dev.exs, so bandit is the HTTP adapter serving the dashboard endpoint
in every environment this example runs in. bb_liveview scopes its copy
only: :dev; this repo does not. The advisories sit in the serving path, not
beside it.

A local mix deps.audit cannot confirm this: the vendored mix_audit 2.1.5
ships no advisory files at all, so it reports "No vulnerabilities found" both
before and after the bump. CI's mix deps.audit + hex.audit job fetches a
current database and is the real check — and it now actually runs, which it
could not do while the compile below was failing.

2. Pick up the released fixes: bb_servo_robotis 0.6.1, bb_liveview 0.3.1

Both carry the changes this example was waiting on:

• bb_servo_robotis 0.6.1 declares c:BB.Actuator.capabilities/1 as
  [:position_feedback], clearing the six ValidatePositionFeedback warnings
  on BB.Example.WX200.Robot (waist, shoulder, elbow, wrist_angle,
  wrist_rotate, left_finger). Those joints were always measured — the
  Dynamixel controller reads present_position off the bus every tick and
  publishes it as JointState — but nothing in the DSL said so, which is
  exactly what the verifier can't see. The fix had to live in the driver, since
  capabilities/1 is a BB.Actuator callback.
• bb_liveview 0.3.1 drops its call to BB.Actuator.set_position!/3, which
  bb 0.30 removed. That error was never in this repo — wx200 contains no
  set_position call at all.

Both were fatal under --warnings-as-errors, and between them they gated every
job in this repo's CI matrix behind MIX_ENV=test mix compile.

Lockfile only: the ~> 0.2 requirements already admitted both versions.

3. Command.Home — don't answer :homed for a move that was refused

Home discarded the result of BB.Motion.send_positions/3 and answered
:homed unconditionally, so BB.Command.await/1 returned {:ok, :homed}
whether the arm homed or nothing moved at all — against a disarmed robot
included. send_positions/2 publishes each command for observers and waits for
the actuator to accept it, so its return value carries the refusal; Home now
passes it through, :ok becoming :homed and {:error, reason} going back
as-is through the result/1 error clause the sibling commands here already
have.

This is a behaviour change, not a port — the old delivery: :direct call still
compiles under bb 0.30 and does exactly what it always did. It's dropped on its
own merits: answering :homed for a move that didn't happen is the same class
of bug beam-bots/bb#235 set out to fix, and 0.30 is what makes it visible,
because before there was no return value to check.

The trade-off is that home() can now fail where it previously always
"succeeded", and it waits for each actuator (bb's default :timeout is 5000ms).
For this arm that's seven ETS writes on a bus the controller is already
ticking, so the wait is negligible.

No test. This repo's test/ carries only the Phoenix scaffolding — none of
the commands are covered — so there's no fixture to extend without building a
robot harness first. Stating that rather than inventing one in a PR this size.

Why the bb floor moves to ~> 0.30

Only this commit needs it, and it needs it precisely because the fix is a
reliance on the new return value. Under 0.29 send_positions/3 answered :ok
whatever happened, so this code would compile clean and go straight back to
reporting :homed for a move that never occurred — the bug it exists to fix,
silently reintroduced. An unchecked return fails quietly at runtime where a
removed function fails loudly at compile time, so the floor rules 0.29 out.
Released bb 0.30.0 specs it as :ok | {:error, motion_error()}, which is what
Home now matches on.

Verification

mix check --no-retry with everything resolving from hex — no BB_VERSION,
no path deps, exactly what CI does — passes all ten stages: compiler, credo,
dialyzer, ex_unit, ex_doc, formatter, gettext, mix_audit, reuse, unused_deps.

Specifically confirmed rather than inferred from the green compile:

• Zero ValidatePositionFeedback warnings. Grepping the full check output
  for the warning text returns 0 matches, down from 36 occurrences across the
  dev and test compiles.
• Zero set_position! references anywhere in the build output, down from 4.
• mix deps.unlock --check-unused passes, and mix.exs is untouched by
  commits 1 and 2 — both are lockfile-only.

mix deps.update wanted to drag localize, nx, req, phoenix and
phoenix_live_view along with the intended bumps; those were reverted and only
the lines meant to change were re-applied. Each dependency commit is a
two-line-or-less lockfile diff.