Regex can bypass strict-tag policy when request_tags is empty

The inline comment says "Allow the regex to fire only when the deployment has NO plain tags," but the actual guard condition checks not match_any AND bool(deployment_tags) AND bool(request_tags). When a request carries no tags at all (request_tags is None or []), bool(request_tags) is False, so strict_tag_check_failed is always False — even when match_any=False and the deployment has both tags and tag_regex.

This means a deployment that an operator deliberately locks down with strict tag requirements (match_any=False + non-empty tags) can still be reached by any request that has a matching User-Agent, even if that request provides zero tags. The doc comment and the runtime behaviour disagree.

Suggested fix – make the guard honour the "no plain tags" intent from the comment:

# Allow regex only when the deployment has no plain tags
# OR when the strict-tag check did NOT already run and fail.
strict_tag_check_failed = (
    not match_any and bool(deployment_tags) and bool(request_tags)
)
# Only fire regex when the deployment has no plain tags, or the tag
# check hasn't blocked it.
regex_allowed = not deployment_tags or not strict_tag_check_failed
if deployment_tag_regex and header_strings and regex_allowed:

Or, more simply, skip the regex entirely when the deployment has both tags and tag_regex and strict mode is on:

strict_tag_check_failed = not match_any and bool(deployment_tags)

(removing and bool(request_tags) so strict mode applies even when the request sends no tags).

LITELLM_NON_ROOT env var silently removed – backwards-incompatible

The previous code honoured LITELLM_NON_ROOT=true to redirect the tiktoken cache to /tmp/tiktoken_cache for read-only, non-root Docker environments. This PR deletes that branch entirely, so any deployment that sets LITELLM_NON_ROOT=true (e.g., distroless or hardened containers) will silently receive no benefit and may hit permission errors if tiktoken tries to write to the read-only package directory.

Per the project's backwards-compatibility rule, behaviour that users rely on should not be removed without a migration path or feature flag.

Suggested approach – keep backward compat while cleaning up the logic:

Rule Used: What: avoid backwards-incompatible changes without... (source)

Mock updated to match new (potentially broken) behaviour

The original test_tiktoken_cache_fallback test specifically verified that LITELLM_NON_ROOT=true causes a fallback to /tmp/tiktoken_cache in read-only environments — a regression guard for non-root Docker deployments. The replacement test (test_default_encoding_uses_bundled_tokenizers_by_default) now asserts the opposite behaviour: that LITELLM_NON_ROOT=true has no effect.

If the intent of this PR is to intentionally drop support for LITELLM_NON_ROOT, the test change is consistent — but per the mock-integrity rule, changing a test to match code that introduces a potential regression (breaking existing deployments) is the pattern to avoid. The old mock was a valid regression detector and should be kept (or the feature should be preserved with a deprecation notice) rather than silently deleted.

Rule Used: # Code Review Rule: Mock Test Integrity

What:... (source)