Consider supporting `Content-Disposition: inline` for some attachment types

### Description

From the user perspective, it would be beneficial in some cases to let the browser display attachments (i.e. PDF files) instead of only letting the user download them. It's most important to consider the security risks here, and build a whitelist for certain file types we should allow.

### Risks
- Files that can run javascript (this could be possible in PDFs) may be able to run in a trusted context if served from our domain, thus they could steal cookies/run requests with cookies/etc. The suggested mitigation is tight CSP rules, but we might also consider serving from a separate domain if possible.

### Relevant issues

See discussions here:
- https://digdir.slack.com/archives/C0760NPT2BE/p1772184700002149
- https://digdir.slack.com/archives/C075WJSDVQC/p1780656573900489 (mostly a link to the first one)

No files, tests, or entry points are named. Start by reviewing the two linked Slack discussions and locating the attachment response handling in the repository. Done requires an agreed security model, including which attachment types may be displayed inline and how trusted-context risks are mitigated.

Written by the indexing model from the issue text.