Build document attachment collector for activities

Model the collection phase as a dedicated method `collectAttachmentManifest(String organisationId, String reportPeriodId)` on the `BufdirAttachmentBundler` class. Use a Supabase join query on the attachments table filtered by `organisation_id` and a subquery of activity IDs within the report period — avoid multiple round-trips. Batch signed URL creation using `supabase.storage.from(bucket).createSignedUrls(paths, expiresIn)` which accepts a list — this avoids N+1 calls. For availability validation, use `Future.wait` with a pool pattern (e.g.

`package:async`'s `Pool`) capped at 10 concurrent requests. Define `BufdirAttachmentManifestEntry` as an immutable Dart class with `copyWith`. Log warnings via a structured logger, not `print()`. Store the manifest as a `List` in a `BufdirExportContext` object passed to the next pipeline phase (task-009).

Ensure the method is `async` and returns `Future>` — never void.

Unit tests (flutter_test with Mockito or mocktail) must cover: (1) happy path — mock Supabase returning 3 attachments for 2 activities, assert manifest has 3 entries with correct field values; (2) unavailable file — one attachment returns 404 on availability check, assert it is excluded and a warning is emitted; (3) empty scope — no activities in period, assert empty manifest returned without exception; (4) RLS boundary — query executed with wrong org context returns empty result, assert no crash; (5) partial failure — 2 of 5 signed URL generations fail, assert 3 entries in manifest with 2 warnings logged. Integration tests against a Supabase test project should cover the full collection cycle with real Storage objects. Test coverage for BufdirAttachmentBundler collection phase must be at least 90%.