User story: an operator connects the SPARC'd tools to their own object store

The tools work alongside any S3-compatible store, but no user story covers the person who owns that store. Right now what the tools do with a misconfigured bucket or a narrow credential is decided in code, one issue at a time, with no requirement to check the behaviour against. That is how we end up with an upload that fails halfway through instead of a message on connect.

Where: the wiki at https://github.com/CulverLab/sparcd-requirements/wiki/User-Stories has personas for contributors, taggers and agency evaluators, but none for whoever administers the storage.

What to do:

Add a persona and stories covering:

1. I point the tools at my own S3-compatible store and they work.
2. When something is misconfigured I am told plainly what and where. CORS, credentials and permissions each need their own message.
3. The apps only offer what my credential actually allows.

Leave the persona name to whoever writes it up.

Evidence from the sparcd-exploration repo: CulverLab/sparcd-exploration#87, CulverLab/sparcd-exploration#191 on the Jetstream migration, CulverLab/sparcd-exploration#197 on the provider matrix, plus three new issues: CulverLab/sparcd-exploration#202 (read-only credential gating), CulverLab/sparcd-exploration#203 (permissions matrix in CI) and CulverLab/sparcd-exploration#199 (long-host header bug). All three had to invent requirements to make a decision.

Done when:

- [ ] Persona added to the wiki
- [ ] At least three stories covering connect, diagnose and permission scope
- [ ] Each story has acceptance criteria a test can check
- [ ] The exploration issues above link to the new IDs

One thing to fix while in there: the wiki reuses F1 and J1 for two different stories each, which makes "serves story F1" ambiguous.

Serves user story: RAJ1, T2

Start with the existing personas and stories in the User-Stories wiki, then review exploration issues #87, #191, #197, #202, #203, and #199 for the requirements they needed. Add the storage-admin persona, connect/diagnose/permission stories with testable acceptance criteria, resolve duplicate F1 and J1 identifiers, and link the exploration issues to the new story IDs.

Written by the indexing model from the issue text.