Pass tenant context (name/id) to JavaScript providers

[KrisSimon]

Summary

Tenant JavaScript providers (UserLoginProvider / UserValidationProvider) previously received only the username/password. That is not enough to talk to an external, multi-tenant user service such as Uitrusting, whose API is scoped by tenant (e.g. /tenants/{tenantId}/users). This PR exposes the tenant to the provider script.

What changed

The constructor argument now carries a nested tenant object:

class UserLoginProvider {
  constructor(credentials) {
    const tenantName = credentials.tenant.name;   // always present
    const tenantId   = credentials.tenant.id;     // Kubernetes CRD UID; null for file-based tenants
    // … authenticate against the tenant-scoped external service …
  }
}

• New JSInputTenant { name, id } — id is the Kubernetes CRD UID when the tenant is loaded from a CRD, nil for file-based tenants (identify those by name).
• tenant added to JSInputCredentials and JSInputUsername.
• Threaded through all four provider call sites: LoginController (interactive login), ActivateController (device grant), the password grant, and UserValidation (refresh-token re-validation).

The field is additive — existing provider scripts that ignore tenant keep working unchanged.

Tests

• UserLoginTenantContextTest (new): a provider script reads credentials.tenant.name/.id and the values are asserted end-to-end; plus JSInputTenant(from:) mapping for Kubernetes vs. file tenant refs.
• Updated JSInputParameterTest and the other provider tests for the new field (encode/decode/round-trip).

Verification

• swift build clean; provider + controller suites 102/102 pass; ./tooling.sh lint 0 violations.
• Not run: full e2e suite (needs a kind cluster).