Summary

Fix SFTP LOGICAL home directory mappings when the mapping entry is /.

Previously, a root mapping did not match normal SFTP paths because the resolver built the match prefix as entry + "/". For Entry="/", that produced "//", so paths like /users.csv failed to match the configured mapping and fell through to the unmapped fallback behavior.

This change treats / as its own prefix while preserving the existing behavior for non-root mappings.

Examples

Given this Transfer user configuration:

{
  "HomeDirectoryType": "LOGICAL",
  "HomeDirectoryMappings": [
    {
      "Entry": "/",
      "Target": "/my-sftp-bucket"
    }
  ]
}

Expected behavior:

Before this fix, /users.csv did not match the / entry because the code checked for a "//" prefix.

Non-root mappings still behave the same:

{
  "HomeDirectoryType": "LOGICAL",
  "HomeDirectoryMappings": [
    {
      "Entry": "/inbox",
      "Target": "/my-sftp-bucket/incoming"
    }
  ]
}

Longest-prefix matching is preserved when root and more specific mappings are combined:

{
  "HomeDirectoryType": "LOGICAL",
  "HomeDirectoryMappings": [
    {
      "Entry": "/",
      "Target": "/my-sftp-bucket/root"
    },
    {
      "Entry": "/inbox",
      "Target": "/my-sftp-bucket/incoming"
    }
  ]
}

Testing

Added an end-to-end regression test which:

1. Creates a Transfer user with HomeDirectoryType="LOGICAL" and Entry="/".
2. Uploads /users.csv through SFTP.
3. Reads the same file back through SFTP.
4. Verifies the object exists in S3 at users.csv.