MDMAndroidCommand maps to the mdm_android_commands table. Status and type values
mirror the strings AMAPI uses on the wire so the same enum doubles as the value we
send in IssueCommand and the value we read back from Pub/Sub COMMAND notifications.

Adds the four CRUD methods Fleet needs at AMAPI command-issue and
Pub/Sub COMMAND-notification time:

- NewMDMAndroidCommand: insert at issue time (auto-generates command_uuid
  if caller leaves it empty)
- GetMDMAndroidCommandByUUID: lookup by Fleet command_uuid (the value
  host_mdm_actions.{lock_ref, wipe_ref} points to)
- GetMDMAndroidCommandByOperationName: lookup by AMAPI operation name,
  used by the Pub/Sub handler to correlate a notification back to the
  originating Fleet command
- UpdateMDMAndroidCommandStatus: transition status (and optional error
  code/message) when the device acks or AMAPI rejects

Interface declared on fleet.Datastore (mirrors NewAndroidPolicyRequest /
GetAndroidPolicyRequestByUUID), with matching mock entries and an
integration test exercising all four methods plus NotFound paths.

Teaches HostLockWipeStatus to interpret AMAPI lock/wipe state stored in
mdm_android_commands, so the existing PendingAction / DeviceStatus /
IsLocked / IsWiped helpers work for android hosts the same way they do
for darwin, ios, ipados, windows, and linux.

- GetHostLockWipeStatus: new android case that maps lock_ref/wipe_ref
  through mdm_android_commands and populates Lock/WipeMDMCommand +
  Lock/WipeMDMCommandResult. Pending status leaves the result nil so
  IsPendingLock/IsPendingWipe report "pending". Orphan refs log and
  return zero-state (mirrors apple/windows).
- GetHostsLockWipeStatusBatch: matching android collection + batch
  query against mdm_android_commands.
- HostLockWipeStatus methods (server/fleet/scripts.go): android arms
  added to IsPendingLock, IsPendingWipe (covered by the existing fall
  through), IsLocked, and IsWiped. They compare against the literal
  "acknowledged" string (the value of
  android.MDMAndroidCommandStatusAcknowledged) to avoid pulling the
  android package into server/fleet.

Wires the Android Management API IssueCommand endpoint through Fleet's
three Client implementations so the service layer can dispatch LOCK,
RESET_PASSWORD, and WIPE commands to enrolled Android devices:

- Client interface (androidmgmt/client.go): add the method declaration
  with a docstring pointing at the AMAPI reference.
- GoogleClient: direct AMAPI passthrough with the standard error
  wrapping pattern used by neighbouring methods.
- ProxyClient: same passthrough, plus the Authorization: Bearer header
  the proxy needs for every call.
- mock/Client: hand-maintained mock additions (Func type, struct field
  + Invoked flag, method wrapper) so service-layer tests can swap in
  fakes without contacting real AMAPI.

Validated by porting the spike code that exercised this against real
BYO and COBO devices for all three command types.

Replaces the spike's log-only implementations with the real
issue-and-persist flow:

1. Service layer (server/mdm/android/service.go + service/service.go):
   - LockAndroidHost: AMAPI LOCK -> NewMDMAndroidCommand +
     host_mdm_actions.lock_ref (via LockHostViaAndroidMDM).
   - ClearAndroidPasscode: AMAPI RESET_PASSWORD with newPassword=""
     (clears, does not regenerate, per product); persists the row but
     does NOT touch host_mdm_actions (one-shot, no UI state).
   - WipeAndroidHost: AMAPI WIPE -> NewMDMAndroidCommand +
     host_mdm_actions.wipe_ref (via WipeHostViaAndroidMDM). WipeParams
     intentionally set to an empty struct -- the spike confirmed AMAPI
     rejects WIPE without it, despite the SDK marking it Optional.
   - resolveAndroidCommandTarget helper centralises the host/enterprise
     lookup + secret refresh shared by all three methods.
   - longCommandDuration = "315360000s" (10 years) on every command, so
     undelivered commands stay queued forever -- matches Apple/Windows
     MDM semantics. AMAPI default of 600s would silently expire.

2. Datastore (server/fleet/datastore.go + datastore/mysql/android.go):
   - LockHostViaAndroidMDM / WipeHostViaAndroidMDM: transactional
     two-write helpers that insert the mdm_android_commands row and
     upsert host_mdm_actions in a single retried tx. Mirrors
     WipeHostViaWindowsMDM. Generated mocks updated.
   - Integration tests cover the lock-pending path and the wipe-requeue
     path (later wipe_ref overwrites earlier, both command rows preserved
     for audit).

Pub/Sub COMMAND ack handling (Phase 9) and EE dispatch (Phase 10) are
follow-ups; this commit gets the command-issue side end-to-end.

Per product (2026-05-20): unenrolling a BYO Android host should run an
AMAPI WIPE command, which on a personal device only wipes the
work profile and leaves the personal side intact. The mdm_unenrolled
activity is still emitted on the subsequent Pub/Sub COMMAND path
(unchanged from the previous behavior). COBO unenroll keeps the existing
EnterprisesDevicesDelete call -- it terminates management without
factory-resetting the device.

UnenrollAndroidHost branches on host_mdm.is_personal_enrollment. The
BYO branch persists an mdm_android_commands row (audit trail) but does
NOT write host_mdm_actions.wipe_ref, because BYO unenroll surfaces in
the UI as "unenroll", not as a wipe.

AMAPI delivers a COMMAND notification when a device acks (or rejects) an
issued command. The notification is an Operation envelope whose Name
matches the operation_name we recorded at IssueCommand time. This commit
turns the spike's log-only handler into a real state machine:

- Decodes the payload as androidmanagement.Operation.
- Looks up the Fleet row by operation_name. NotFound (e.g. a command
  issued from a previous deployment) is acked without retry to keep
  Pub/Sub from looping.
- Empty op.Name is logged and acked (malformed/foreign payload).
- If op.Error is set, transitions the row to "error" with error_code
  (the int google.rpc.Code rendered as string) and error_message.
- Otherwise transitions to "acknowledged".
- Already-terminal rows are ignored -- AMAPI delivers at-least-once, so
  we must be idempotent.

host_mdm_actions does not need a separate update because the android
branch of GetHostLockWipeStatus reads the row status string directly,
and HostLockWipeStatus.IsLocked/IsWiped compare against "acknowledged".

Unit tests cover all five paths (ack, error, idempotent re-delivery,
unknown op, empty op.Name).

Threads the android.Service Lock/Wipe/ClearPasscode helpers (added in
the previous commit) into the EE Service layer so they're reachable from
the existing /hosts/:id/lock, /hosts/:id/wipe, /hosts/:id/mdm/passcode
API endpoints.

- LockHost case "android": validates AndroidEnabledAndConfigured +
  IsHostConnectedToFleetMDM. Lock is supported on both BYO and COBO.
- enqueueLockHostRequest case "android": dispatches to LockAndroidHost
  and explicitly resets activity.ViewPIN -- Android has no unlock PIN.
- WipeHost case "android": rejects BYO with a descriptive error
  (BYO unenroll already runs an AMAPI WIPE under the hood) and
  validates AndroidEnabledAndConfigured. requireMDM is set so the
  existing MDM-connection precondition runs.
- enqueueWipeHostRequest case "android": dispatches to WipeAndroidHost.
- ClearPasscode: new clearPasscodeAndroid branch mirroring
  clearPasscodeApple's shape. Validates AndroidEnabledAndConfigured,
  dispatches to ClearAndroidPasscode, emits the existing
  cleared_passcode activity (shared with Apple), returns a
  CommandEnqueueResult shaped for API compatibility. Error message
  updated to mention Android.

Mirrors the existing lock/unlock/wipe subcommands and exposes clear-
passcode at the CLI for iOS/iPadOS (existing) and Android (new in
this PR). The server endpoint at /hosts/:id/clear_passcode already
dispatches by platform, so the CLI doesn't need android-specific
branching.

- Promotes the previously-private clearPasscodeResponse to
  fleet.ClearPasscodeResponse, matching LockHostResponse /
  WipeHostResponse and letting client + server share the type.
- Adds Client.MDMClearPasscodeHost in server/service/client_mdm.go.
- Adds mdmClearPasscodeCommand in cmd/fleetctl/fleetctl/mdm.go and
  registers it under `fleetctl mdm clear-passcode` (alias
  clear_passcode).
- Unit test TestMDMClearPasscodeCommand exercises the failure paths
  (missing flag, unknown host, MDM-off). Happy paths against real
  iOS/Android hosts are covered by integration tests.

End-to-end coverage against the real Fleet HTTP handler stack with the
mock AMAPI client. Verifies that for each command the API endpoint
issues the right AMAPI call, persists the mdm_android_commands row,
updates host_mdm_actions where applicable, and surfaces the right
device/pending status on the host detail endpoint.

- TestAndroidHostUnenrollMDM: updated to match the new BYO behavior
  -- BYO unenroll now issues an AMAPI WIPE (work-profile only), not
  EnterprisesDevicesDelete. Added a COBO sub-case to assert the
  delete path is still used for company-owned hosts.
- TestAndroidLockWipeClearPasscode (new):
  - Lock COBO: AMAPI LOCK + Duration=315360000s; GET host returns
    PendingAction=lock + DeviceStatus=unlocked; Pub/Sub COMMAND ack
    transitions the row to acknowledged and the host page to locked.
  - Wipe BYO rejected with the "personally-owned" error message.
  - Wipe COBO: AMAPI WIPE with non-nil empty WipeParams + long
    duration; PendingAction=wipe surfaces.
  - Clear passcode: AMAPI RESET_PASSWORD with newPassword=""; no
    host_mdm_actions write.
  - Pub/Sub COMMAND with op.Error transitions the row to "error" and
    populates error_code (the int rpc code as string) and
    error_message.

To support both BYO and COBO test fixtures, factored
createAndroidHostWithStorage into createAndroidHostForTest taking an
explicit companyOwned bool; the existing helper now just wraps it for
BYO callers.

Also replaced the private clearPasscodeResponse reference in the
existing iOS clear-passcode integration test with the public
fleet.ClearPasscodeResponse promoted earlier in this branch.

…commands-backend

# Conflicts:
#	server/datastore/mysql/schema.sql

After merging main (#46079 renumbered 11 migrations to 20260522195224-..235),
our 20260521205417_AddMDMAndroidCommands ended up before them in the
migration timeline. Bump our timestamp to 20260522195236 so the migration
runs last, and regenerate schema.sql.