Ship a default JDBC AttachmentDataSource, overridable by the application #16

Consuming apps currently have to implement AttachmentDataSource themselves, including a table, a Liquibase changelog, and tests (see aboutbits/boilerplate-api#228). The lib should ship a working default instead, and apps should only override it when they need a different store.

Proposal:

1. Add a JdbcAttachmentDataSource to the lib. It stores payloads in a lib-owned table email_service_attachment_payloads (matches the existing email_service_* naming). Base it on the implementation in aboutbits/boilerplate-api#228, and close the payload stream after reading it (try (payload) { ... }).

2. Register it as the default, replacing UnavailableAttachmentDataSource:

   @Bean
   @ConditionalOnMissingBean(AttachmentDataSource.class)
   public JdbcAttachmentDataSource attachmentDataSource(
           JdbcTemplate jdbcTemplate,
           @Value("${aboutbits.emailservice.migrations.enabled:true}") boolean migrationsEnabled
   ) {
       var dataSource = new JdbcAttachmentDataSource(jdbcTemplate);
       if (migrationsEnabled) {
           dataSource.migrate();
       }
       return dataSource;
   }

3. The default migrates its own table (create table if not exists ...). Because of @ConditionalOnMissingBean, the table is only created when the default is actually used. An app that defines its own AttachmentDataSource bean (for example S3) never triggers it. EmailServiceMigrator stays limited to the core tables.

4. Delete UnavailableAttachmentDataSource.

Result: consuming apps get attachments working out of the box and can delete their own implementation, table changelog, and tests. Overriding stays the same as today: define an AttachmentDataSource bean.

🤖 Generated with Claude Code