Describe the bug

This came up while thinking about #4413. I was looking at these commands:

❯ ref="$(git ls-remote git@github.com:colemickens/redact master|cut -d'  ' -f1)"
❯ nix run "git+ssh://git@github.com/colemickens/redact?rev=$ref&dir=examples/test01" --no-write-lock-file
Hello, world!

And wondered if this meant that nix could be smart enough to only download a small subset of git objects as the VFSForGit progresses, and it could opt to only clone that specific subdirectory. This prompted me to think of edge cases and consider what that might break -- it would break any places that a flake in a subdirectory reached into a parent or sibling directory.

And it seems that this is allowed, based on a test:

❯ cd redact
❯ tree     
.
└── examples
    ├── test01
    │   ├── flake.lock
    │   └── flake.nix
    └── test.txt

❯ cat test.txt
contents_of_testtxt

❯ nix run "git+ssh://git@github.com/colemickens/redact?rev=$ref&dir=examples/test01" --no-write-lock-file
contents_of_testtxt

❯ cd examples/test01; nix run . --no-write-lock-file
contents_of_testtxt

To me this seems a bit surprising. When I see a flake.nix I expect that it seals everything next to, and beneath it. This behavior violates that assumption.

Steps To Reproduce

1. make a git repo
2. make two subdirs
3. place a valid flake.nix in each subdir
4. place a file outside those subdirs
5. use builtins.readFile somehow in one of the flakes to reach "up" and read the file

Note that it works.

Expected behavior

Somehow, nix is able to isolate the directory containing flake.nix to maintain the implied seal of flake.nix

nix-env --version output

Additional context

Alternatively, I could be entirely off the mark and this might intentionally be allowed, but it strikes me as sort of a pretty big mis-match of my expectations when I see a flake.nix.