fix: redact non-string scalar values when key name is sensitive (#71275)

[waterWang]

Description

When a Variable's key name matches the sensitive-keyword list, GET /api/v2/variables correctly returns *** for string values but returns non-string values (int, float, bool) in cleartext, leaking sensitive data.

Root cause

SecretsMasker._redact_all is the fail-closed path used when a key name is judged sensitive, but it only replaces str, recurses into containers, and returns every other type unchanged:

def _redact_all(self, item, depth, max_depth=MAX_RECURSION_DEPTH, *, replacement="***"):
    if depth > max_depth or isinstance(item, str):
        return replacement
    if isinstance(item, dict): ...
    if isinstance(item, (tuple, set)): ...
    if isinstance(item, list): ...
    return item          # <-- non-str scalars pass through unredacted

The comment at lines 353-355 states that key-name-based redaction "must fail closed at any nesting level". It fails closed on depth, but not on type.

Fix

Change the final fall-through in _redact_all from return item to return replacement, so any non-container, non-str scalar (int, float, bool) is also redacted when the key name is sensitive.

Closes #71275

[kaxil]

Closing this as part of a cleanup of a large batch of PRs opened in quick succession from this account.

18 PRs have been opened here in the past two weeks and none have merged. Several show signs of being generated and submitted without review: #71432 and #71433 are the same change across the same five files, opened two minutes apart, and several titles carry a leaked agent identifier that other contributors already flagged as garbled text on #70629 and #71322.

Airflow is maintained by volunteers. Every PR costs reviewer time and CI capacity, so a high volume of unvetted submissions has a real cost to the project.

You are welcome to keep contributing. Please open one change at a time, run it locally against the tests, and read the contributors' guide before submitting. If you think a specific change here is correct, comment with the reasoning and a maintainer can reopen it.