fix(storage): handle null signedURL in createSignedUrls response

[grdsdev]

Summary

When a requested path does not exist, the Storage API returns "signedURL": null for that item. The Flutter SDK was silently producing broken URLs like "${storageUrl}null" with no way for callers to detect the issue. This mirrors the fix applied to the Swift SDK in supabase/supabase-swift#958.

Changes

• types.dart: SignedUrl.signedUrl is now String? (nullable); added optional error: String? field populated from the per-item server error
• storage_file_api.dart: createSignedUrl throws StorageException when the API returns null (consistent with createSignedUploadUrl); createSignedUrls sets signedUrl to null and populates error for missing-path items
• test/basic_test.dart: Added tests for both null-signedURL scenarios; updated existing createSignedUrl test to assert the URL suffix

Root Cause

• storage_file_api.dart:402 — '$url${e['signedURL']}' with a null value produces the literal string "${url}null"
• storage_file_api.dart:370 — same issue in the single-URL variant
• types.dart:250 — signedUrl was non-nullable, making it impossible for callers to detect a missing path

Testing

Reproduction Tests

• createSignedUrl throws StorageException when signedURL is null — previously returned broken URL, now throws
• createSignedUrls returns null signedUrl and error for missing path — previously returned broken URL, now returns signedUrl: null, error: 'not_found'

Test Results

All 37 unit tests pass. Integration tests (client_test.dart) require a live storage server and are unaffected by this change.

Breaking Changes

SignedUrl.signedUrl changes from String to String?. Callers that use this field without a null check will need to be updated. This is intentional — the previous non-null return was a false guarantee.

Acceptance Criteria

• createSignedUrls does not return items with signedUrl == "${storageUrl}null"
• createSignedUrl throws StorageException when the API returns null signedURL
• Unit tests added and passing for both null-signedURL scenarios
• No regression in existing tests

Linear Issue

Closes: SDK-862
Related: SDK-851 (Swift), SDK-842 (Python)

---

🤖 Generated with Claude Code /take

[Vinzent03]

While yeah the previous behavior was not correct this is really a breaking change for everybody using the method for multiple urls. Their code will not compile as Dart is sound. So I would not release this. Either way I wanted to start working now on v3, so we could delay it for v3.

[Vinzent03]

I think we should either keep this comment or remove the null catch for the path field. Or is that also null if signedURL is null?

[Vinzent03]

Does the error field only exists for requesting multiple urls or would that also exist for the case above of a single url request?