fix(security): a driver's password can no longer be set by a general update

[roncodes]

The problem

PUT|PATCH /v1/drivers/{id} passed password straight through:

$userDetails = $request->only(['name', 'password', 'email', 'phone']);
$driverUser->update($userDetails);

Nothing asked for the current password. So anyone holding a driver's token —
or an unlocked handset — could set a new one and own the account. The value is
hashed on the way in, so this is not a storage problem; it is an authorisation
one, which is worse, because everything looks correct afterwards.

Found while building the Navigator redesign: the app had to ship with password
change deliberately disabled because there was no safe way to offer it.

The change

Changing a password is an authorisation decision, not an attribute update, so it
gets its own operations:

Route	Requires
POST /v1/drivers/{id}/change-password	current_password, password (confirmed, min 8)
POST /v1/drivers/forgot-password	identity — sends a code by email or SMS
POST /v1/drivers/reset-password	identity, code, password (confirmed, min 8)

update() no longer accepts password at all. Create still may — setting a
password on an account that does not exist yet proves nothing about anyone.

Follows the pattern already established for customers, and reuses the
VerificationCode mechanism drivers already use for OTP sign-in
(driver_password_reset alongside the existing driver_login).

Three deliberate details

• A change revokes every other token and returns a fresh one. The old
  password should not keep other sessions alive, but a driver changing their
  password mid-shift must not be signed out of the phone in their hand — so the
  caller is re-issued in the same response.
• forgot-password answers identically whether or not the identity exists. A
  reset endpoint that 404s on an unknown number is a way to enumerate a
  company's drivers.
• Wrong code, expired code and unknown identity return the same message, so
  reset cannot be used as an oracle either.

Tests

A regression test asserting a password sent to update() never reaches the
user record.

I could not run it locally. Every test touching a controller in this package
fatals here with Trait "Illuminate\Foundation\Auth\Access\AuthorizesRequests" not found
— the whole file, and identically on a clean checkout of the base branch. It is a
missing illuminate/foundation in the local server_vendor, not this change.
CI has the full install. Flagging rather than implying a green run I did not see.

Worth a second opinion

Revoking other tokens on change is the behaviour I would want as a driver, but it
is a behaviour change for any existing integration that holds long-lived driver
tokens. Happy to drop it if you would rather that landed separately.

---

Two further defects, found while making the Postman collection exercise these endpoints

Both were caught by running the collection against a live instance rather than by the tests, and
both would have made the new endpoints unusable in practice.

A password given at driver creation was never kept. password is guarded on User, so
User::create() dropped it silently — while CreateDriverRequest has always accepted and validated
one. A driver created through the public API could never sign in with the password their operator
chose for them, and the first change-password call was refused because the stored hash was never
theirs. It is now set after creation, where the model's mutator hashes it. (CustomerController
has the same shape at createUser(); left alone as it is outside this PR's subject.)

changePassword compared against a column it could not see. It resolved the account through
Driver::getUser(), which goes through the user relation — and that relation's ->select([...])
names a subset of columns that does not include password. The comparison therefore ran against an
empty string and refused every caller, whatever they typed:

POST /v1/drivers/{id}/change-password   →  422 The current password is incorrect.

with the correct password, against a driver whose stored hash verifies. Calling the same method
in-process on the same driver returns 200. Anything checking a password now loads the record
itself.

Coverage stays at 100%. The helper harness only had the hashing contract and no implementation,
so the mutator had nothing to call; PHP's own hashing is now bound behind the contract so the
password path is actually exercised.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (81dcea2) to head (0f4112c).
⚠️ Report is 3 commits behind head on dev-v0.6.61.

Additional details and impacted files

@@               Coverage Diff                @@
##             dev-v0.6.61      #304    +/-   ##
================================================
  Coverage         100.00%   100.00%            
- Complexity          9829      9866    +37     
================================================
  Files                523       523            
  Lines              37918     38021   +103     
================================================
+ Hits               37918     38021   +103     

Flag	Coverage Δ
backend	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.