`seed buckets` silently skips symlinked files in objects_path

[cvburgess]

Describe the bug

supabase seed buckets (and the bucket seeding that runs as part of supabase db reset / supabase start) silently skips any file in a bucket's objects_path tree that is a symlink. No warning is emitted, so the bucket simply ends up missing those objects.

To Reproduce

1. Declare a seeded bucket in config.toml:

   [storage.buckets.uploads]
   public = true
   objects_path = "./seeds/uploads"

2. Populate ./seeds/uploads/ with relative symlinks pointing at real image files elsewhere in the repo (a common setup to avoid committing duplicate binaries):

   ln -s ../../fixtures/pizza.jpg supabase/seeds/uploads/pizza.jpg

3. Run supabase db reset (or supabase seed buckets).

4. The symlinked files are skipped with no output and no warning. The bucket is empty (or partially populated if the tree mixes regular files and symlinks).

Replacing the symlinks with regular file copies makes the same tree upload correctly.

Expected behavior

Either:

• Follow symlinks to regular files and upload them (stat through the link instead of using the lstat-style entry type), or
• At minimum emit a warning like Skipping non-regular file: <path> so the skip is not silent.

Root cause

In UpsertObjects (apps/cli-go/pkg/storage/batch.go), the fs.WalkDir callback bails out for any non-regular entry:

if !info.Type().IsRegular() {
    return nil
}

fs.DirEntry.Type() reports the lstat mode, so a symlink to a regular file has fs.ModeSymlink set and IsRegular() is false. The check correctly skips directories, but it also drops symlinked files without any diagnostics. Resolving via fs.Stat (or info.Info() on a stat-following FS) for symlink entries, or logging the skip, would fix this.

System information

• Version of OS: macOS 15 (Darwin 25.5.0)
• Version of CLI: v2.105.0
• Version of supabase-js: n/a
• Version of Node.js: n/a

[SahilArate]

Great fix and solid test coverage! A few thoughts that might strengthen this before merge:

1. Double open: isUploadableEntry opens the file to stat it, and then UpsertObjects opens it again for upload. Since fs.FS doesn't expose os.Lstat, one cleaner approach would be to pass the already-opened file handle downstream, or use os.Lstat directly when the underlying FS is an os.DirFS.
2. Logger consistency: The CLI uses structured logging throughout raw fmt.Fprintln(os.Stderr, ...) bypasses --log-level and --output-format json. Worth wiring this through the existing logger so the warning respects user flags.
3. Symlink loop guard: os.Stat follows symlink chains. If someone accidentally creates a circular symlink (a → b → a), this could produce confusing errors. A depth limit or explicit os.Lstat + os.Stat pair with a clear error message would be more defensive.
   Happy to submit a follow-up PR addressing these if helpful!