Snowflake: Avoid mutating caller-supplied properties map during catalog initialization

[wombatu-kun]

Summary

SnowflakeCatalog.initialize(String, Map) adds the JDBC application and user_agent_suffix identifiers by calling properties.put(...) directly on the caller-supplied map. This has two problems: it throws UnsupportedOperationException when the caller passes an immutable map (for example Map.of(...) or ImmutableMap.of(...), which is a contract-legal and idiomatic way to call Catalog.initialize), and even with a mutable map it silently pollutes the caller's map with the two derived JDBC properties.

Every other catalog (JdbcCatalog, GlueCatalog, DynamoDbCatalog, HadoopCatalog, InMemoryCatalog) treats the input properties as read-only and copies them. This change makes SnowflakeCatalog do the same: it builds a mutable copy with Maps.newHashMap(properties), adds the JDBC identifiers to the copy, and passes the copy to the JDBC client pool and catalog initialization, leaving the caller's map untouched.

Tests

Added two tests to TestSnowflakeCatalog: testInitializeWithImmutableProperties verifies that initializing with an immutable properties map no longer throws, and testInitializeDoesNotMutateCallerProperties verifies that a mutable caller map is left unmodified after initialize. Both fail before this change and pass after.