fix(tag_masking_policy_reference): treat a missing database as not-created-yet

[noel]

What

fetch_tag_masking_policy_reference and list_tag_masking_policy_references now treat Snowflake's INVALID_IDENTIFIER (2004) the same as DOES_NOT_EXIST_ERR (2003): a reference that can't be read yet, not a fatal error.

Why

On a fresh Snowflake account, snowcap plan aborted as soon as a config declared tag masking policy references:

002004 (42601): Invalid identifier GOVERNANCE.INFORMATION_SCHEMA.POLICY_REFERENCES

Snowcap reads each reference's state from inside the tag's own database (<database>.INFORMATION_SCHEMA.POLICY_REFERENCES), but that database doesn't exist yet when the same config is also the one creating it. Snowflake can't resolve the qualified table function name in that case, so it returns INVALID_IDENTIFIER rather than DOES_NOT_EXIST_ERR.

Snowcap already handles the equivalent case for roles (missing role → 2003, keeps going). This extends the same "not created yet" treatment to the masking-policy-reference path, so a first plan/apply against a fresh account no longer requires the --exclude tag_masking_policy_reference workaround.

Verified

• Added TestTagMaskingPolicyReferenceMissingDatabase in tests/test_data_provider.py, reproducing the exact 002004 error and confirming it's swallowed for both the fetch and list paths, while other ProgrammingErrors still raise.
• make lint, make typecheck, and the full test suite (2227 passed) all clean.

[github-actions]

Review of PR #79

No issues found.

This is a small, well-scoped fix: list_tag_masking_policy_references and fetch_tag_masking_policy_reference in snowcap/data_provider.py:5241 and snowcap/data_provider.py:5303 now also treat INVALID_IDENTIFIER (2004) as a "reference doesn't exist yet" case, alongside the existing ACCESS_CONTROL_ERR, UNSUPPORTED_FEATURE, and DOES_NOT_EXIST_ERR codes. This matches existing precedent elsewhere in the same file (snowcap/data_provider.py:3809 already treats INVALID_IDENTIFIER the same way for a different resource), so it's consistent with the codebase's established error-handling pattern rather than a one-off special case.

The change correctly narrows to ProgrammingError with a specific errno, still re-raises on any other error code (verified by the new test_fetch_raises_on_other_programming_errors test), and is backed by three new focused unit tests in tests/test_data_provider.py covering the fetch-returns-None, fetch-still-raises, and list-skips-and-continues cases. No unsafe string interpolation, credential literals, or architectural concerns in this diff.