Evaluate attribute-based Access Policy checks (OS type) on mobile devices — enable selective mobile access

Summary:
Access Policies expose Android and iOS as selectable operating-system attribute criteria, but these attribute-based checks are not actually evaluated on mobile clients — only behavior-based checks are. A policy matching on Timus Connect: Operating System contains iOS or Android does not enforce as expected; the OS attribute check is silently skipped. Engineering confirmed this is current behavior. This should either work on mobile, or the unsupported criteria should not be selectable in the policy UI.

Use case:
We need to allow Timus Connect mobile access for a specific, approved set of users while blocking it for everyone else. This is a common BYOD/managed-access requirement in regulated environments.

Why the current workarounds don't fit:

• Device Approval applies to all OS types and only affects devices registered after enablement. It can't target mobile specifically, nor allow a defined subset while blocking the rest.
• Dynamic Tagging + firewall Deny rule (tag on OS = iOS/Android → deny) blocks mobile broadly but gives no way to allow specific approved devices. It's all-or-nothing at the OS level.

Requested behavior:

1. Evaluate OS (and other device) attribute checks on Android and iOS within Access Policies, Detectors, and Responders — matching desktop client behavior.
2. Allow policies combining an OS/mobile match with an allow-list of specific users or devices (e.g., "block mobile Timus Connect except for these approved users").
3. Until attribute checks are supported on mobile, hide or clearly flag the unsupported criteria in the policy UI so admins aren't misled by selectable-but-ignored options.

Possible overlap:
This is related to but distinct from "Ability to Disable Mobile Application Access" (https://support.timusnetworks.com/hc/en-us/community/posts/43226460004115), which requests a blanket Agent Profile toggle to disable mobile sign-in entirely. This request is for granular, attribute-driven control — selectively allowing specific users/devices rather than an all-or-nothing switch. The two could be addressed together.