feat: replace afero-s3 with minimal in-tree S3 implementation

[maggch97]

Summary

Replaces the third-party fclairamb/afero-s3 library (and its temporary fork) with a minimal in-tree afero.Fs implementation (~200 lines) that only supports the three S3 operations Vikunja actually uses:

• Open → HeadObject (existence check) + lazy GetObject on first Read
• Remove → HeadObject + DeleteObject
• Stat → HeadObject

All other afero.Fs/afero.File methods return ErrS3NotSupported since they are never called in the S3 code path (writes already use direct PutObject).

Changes

1. pkg/files/s3fs.go (new) — Minimal S3 afero.Fs + afero.File + os.FileInfo implementation
2. pkg/files/filehandling.go — Replace aferos3.NewFsFromClient() with newS3Fs()
3. pkg/routes/api/v1/user_export.go — Add S3 branch for export download (io.Copy instead of http.ServeContent which requires io.ReadSeeker)
4. go.mod / go.sum — Remove fclairamb/afero-s3 dependency and replace directive

Why

• Removes dependency on a library that caused a severe S3 read performance regression (fix(deps): use forked afero-s3 to fix S3 read performance regression #2313)
• Removes the temporary fork replace directive
• The full afero-s3 library implements ~400 lines of S3 operations we never use (Create, Mkdir, Rename, Chmod, Write streams, Readdir, etc.)
• Our implementation is small enough to maintain in-tree with minimal effort

Closes #2347

[kolaente]

No create or write? how exactly does that work then to create upload attachments?

[maggch97]

That's handled by

vikunja/pkg/files/files.go

Line 176 in c6f0d8b

func writeToStorage(path string, content io.ReadSeeker, size uint64) error {

[kolaente]

Okay, but if we're bypassing the s3 fs there already, what advantage do we have to reimplement it? (albeit partially)