CLI Status command must validate User in the smart contract

[juan-malbeclabs]

Background

Currently, when a user is disconnected unilaterally from Serviceability (e.g., removed or banned), the client remains unaware of the change. As a result, the CLI continues to report the tunnel as if it were still active, even though the Serviceability program has already invalidated the user.

This creates inconsistent states where the local daemon and the Serviceability smart contract disagree about the actual connection status.

Problem Demonstration

$ doublezero status
 Tunnel status | Last Session Update     | Tunnel Name | Tunnel src      | Tunnel dst | Doublezero IP   | User Type
 unknown       | 1970-01-01 00:00:00 UTC | doublezero0 | 137.174.145.138 | 100.0.0.1  | 137.174.145.138 | IBRL

User is removed unilaterally from Serviceability.
Running a disconnect shows deprovisioning:

$ doublezero disconnect
DoubleZero Service Provisioning
🔍  Decommissioning User
Public IP detected: 137.174.145.138 - If you want to use a different IP, you can specify it with `--client-ip x.x.x.x`
✅  Deprovisioning Complete

However, running status again still produces misleading output:

$ doublezero status
 Tunnel status | Last Session Update     | Tunnel Name | Tunnel src      | Tunnel dst | Doublezero IP   | User Type
 unknown       | 1970-01-01 00:00:00 UTC | doublezero0 | 137.174.145.138 | 100.0.0.1  | 137.174.145.138 | IBRL

Expected Behavior

• The status command must check the User record in the Serviceability smart contract.
• If the user no longer exists or is marked as banned:
  • The CLI should not display an “unknown” session.
  • Instead, it must return a clear error message stating that the user is no longer valid in Serviceability.

Proposed Solution

• Add a validation step in status that queries Serviceability.
• If the User account is missing or flagged as banned, show:

Error: User not found in Serviceability or has been banned. Please reconnect with a valid AccessPass.

This ensures users are immediately aware that their session is invalid and prevents misleading states between the daemon and Serviceability.