Document service accounts and operator mode in the README

The last commit (a4dd60f) shipped the code with no README update, against
this repo's own convention of documenting the whole API surface there.
Adds the Service accounts section and table, the Authentication and Teams
prose covering the new principal and TERDUT_OPERATOR_MODE, and the
/api/version row.

Corrects one thing along the way: a first draft claimed team-scoped
accounts are refused on team membership/invite endpoints. Checked against
teams.go and that is false — nothing server-side carves those two out,
only convention (no sane operator would call them) keeps them out of
automation's hands. README and SERVICE-ACCOUNTS.md now say that plainly
instead of the stronger, incorrect claim.

SERVICE-ACCOUNTS.md

@@ -138,6 +138,20 @@ identity is recorded for a human (incident timeline
 principal is stored and displayed distinctly, e.g. `service-account:terdut-operator`,
 never coerced into a `user_id` FK.
 
+**Team scope, as implemented, is owner-equivalent for every `requireTeamOwner`
+endpoint, membership and invites included — nothing server-side carves those
+two out.** That's broader than what `terdut-operator`'s CRDs actually need
+(escalation/deadman/integrations/OIDC-bindings only; membership is explicitly
+never gitops-managed, see its DESIGN.md §4.2), a gap acknowledged rather than
+closed here: narrowing this to exclude
+`POST/DELETE /api/teams/{teamID}/members*` and
+`.../invites*` specifically for a service-account caller is a small, isolated
+follow-up (special-case those handlers rather than `requireTeamOwner` itself,
+which every other owner-gated endpoint still wants shared). Until then, what
+actually keeps membership out of automation's hands is that no operator built
+against this scope should ever call those two endpoints — not a server-side
+refusal.
+
 ## What this unblocks
 
 Directly resolves `terdut-operator` DESIGN.md §6's two broken assumptions: