[rootkiller6788]

Two things in remote_config.py don't line up with how the same evaluator behaves in firebase-admin-node, plus a type annotation that is plain wrong.

1. A custom signal whose value is 0 or '' is treated as if the signal were not in the context at all, because it is read with context.get(key) or {} and then checked for truthiness. So {"user_level": 0} can never match NUMERIC_EQUAL with target '0'. The context is typed Dict[str, Union[str, int]], so 0 is a perfectly valid signal value. The signal is now only considered missing when the context has no entry for it, same as the Node SDK.

2. A conditional value or default value entry without a value field (for example {"useInAppDefault": false}) produced a Value backed by None, so get_string() handed back the literal string 'None' and get_int() blew up with a TypeError out of int(None). Conditional values without an explicit value now leave the in-app default in place, and a Value never holds None.

I also corrected the as_int() return annotation, which is int and not float - that part comes from #957 (the other half of that issue, the or {} fallbacks for the string/list fields, is covered by the change above).

Testing: new unit tests in tests/test_remote_config.py; all of them fail on main. The module suite is green (36 passed) and pylint is clean on the changed files.

[gemini-code-assist]

Code Review

This pull request improves Remote Config evaluation logic by handling conditional values without explicit values, ensuring falsy custom signal values (like 0 or empty strings) are correctly evaluated instead of treated as absent, and fixing type annotations and fallback values. It also adds corresponding unit tests. The feedback highlights a critical issue in the new tests where mutating the global SERVER_REMOTE_CONFIG_RESPONSE dictionary directly can cause test pollution; using .copy() is recommended to avoid flaky tests.