Fix snow stage copy --recursive dropping FQN qualifiers

[sfc-gh-moczko]

Summary

• Fixed iter_stage() in StageManager silently dropping database and schema qualifiers from fully-qualified stage names during recursive copy, causing GET commands to resolve against the connection's default database instead of the one specified in the FQN.

Problem

When running snow stage copy @db.schema.stage/path/ ./local --recursive, the generated GET commands would use @stage/... instead of @db.schema.stage/.... This happened because Snowflake's ls command returns file names with only the unqualified stage name (e.g., stage/path/file.txt), and iter_stage() passed that directly to build_path(), which reconstructed a new StagePath without the original FQN qualifiers.

Root cause

In StageManager.iter_stage(), the else branch called self.build_path(file["name"]) where file["name"] from ls output contains only the bare stage name. build_path → StagePath.from_stage_str() parsed this as a new unqualified stage, discarding the database/schema from the original user input.

Fix

Extract the relative file path from ls output by splitting off the unqualified stage name prefix, then join it with stage_path.root_path() which preserves the original FQN from user input.

Test plan

• Added 5 parametrized test cases to test_copy_get_recursive covering: FQN root (@db.schema.exe), FQN with trailing slash, FQN with subdirectory, FQN with specific file, and schema-qualified (@schema.exe)
• All 17 recursive copy tests pass (8 existing + 5 new FQN + 4 user stage)
• Full stage test suite passes (319 tests, 50 snapshots)
• Verified tests catch regression: reverting the fix causes FQN test cases to fail (GET commands show @exe/... instead of @db.schema.exe/...)