Relax fileExtension requirement in attachmentQueue

[n0mad-d3v]

Hello powersync team 👋

This PR fixes #268 and updates the watchIds method in the Attachments helper to make the fileExtension parameter optional. This enables support for storing files with different extensions in the same attachmentQueue, which is useful in cases where:

• The extension is already part of the filename (e.g., managed directly in the storage bucket like Supabase).
• The developer wants more flexibility in handling mixed file types under a unified queue.

Motivation: Currently, the API assumes a single extension per queue, which limits use cases that involve multiple file types. Making fileExtension optional opens up broader usage while maintaining backward compatibility.

⚠️ This includes a breaking change. And along that, I'm wondering if it shouldn't be pushed further to be able to specify a Map<String, String?> for <filename, extension?> in the whatchIds to allow even more flexibility and usecases.

This change was inspired by this Discord thread.

WDYT? Looking forward to feedback!

PS: There is also a change about ensuring directory creation. In my usecase, I'm using Teams' ids as subdirectory so it's fully dynamic and my filename is like the following:
{teamId}/{attachmentType}/{attachmentId}.{attachmentExtension}.

[stevensJourney]

Thanks for the work done here. I recognise some of the current limitations the Dart Attachments helper has. This is an improvement.

I recently worked on the Kotlin and Swift Attachment helpers. I also noticed this inconvenience during development and opted for a different approach which might align better with your thought of

I'm wondering if it shouldn't be pushed further to be able to specify a Map<String, String?> for <filename, extension?>

The Kotlin and Swift implementations allow the watched query to return more than just the attachment ID. They allow returning an array of "partial attachments" which can include a filename and fileExtension. These values are resolved if not provided.

I personally am in favour of updating the watched query result to contain a partial Attachment record type which can contain more information.

[n0mad-d3v]

Hi @stevensJourney, thanks for the feedback! It's interesting to see that the question raised in other technos as well and that a common ground has been found to tackle this issue. Of course, I think consistency is key as Powersync users expect it when using the library from one stack to another.

I'll have a deeper look in your changes and try to adapt my PR asap 🤓