Make CLI login resilient to workspace id key rename in device metadata

[qubeena07]

Summary

zenml login for Pro servers reads the selected workspace id out of the device metadata dict returned by the auth server. The code only ever looked at the tenant_id key and had a TODO questioning whether that was still correct. Nothing else in the login flow uses the word tenant anymore, the web login request itself sends the hint as workspace, so a server side rename would have silently dropped the workspace selection with no error, just the generic fallback message asking the user to pick a server manually.

Changes

• Try workspace_id first, then fall back to the legacy tenant_id key
• Log a debug message when neither key is present so the miss is at least traceable instead of fully silent

Note

device_metadata is an untyped dict sourced entirely from the Pro auth server, which lives outside this repo, so I could not directly confirm the current key name from here. This change is a safe fallback rather than a guess at a single replacement key.

Fixes #5111

Test plan

• ruff check src/zenml/cli/login.py passes
• Manual login against a Pro server to confirm workspace selection still resolves correctly

[qubeena07]

I do not have permission to add labels here. Could a maintainer add the no release notes label please, this is an internal bug fix with no user facing changes. Also flagging that the linting and pr labeler check failures are pre existing and unrelated to this change, the same mypy failures in hashicorp_secrets_store.py show up on other recent PRs into develop such as #5105.