Finish OAuth account-scope cleanup before 1.0

[chubes4]

Problem

Current origin/main still has OAuth account-scope compatibility seams that keep the 1.0 auth contract muddy.

Code references on origin/main (008878b6):

• inc/Core/OAuth/BaseAuthProvider.php:317 — get_account( array $context = array() ) compatibility entry point.
• inc/Core/OAuth/BaseAuthProvider.php:357 — get_account_for_context() preserves policy/site fallback semantics.
• inc/Core/OAuth/BaseAuthProvider.php:412 — save_account( ..., array $context ) compatibility entry point.
• inc/Core/OAuth/BaseAuthProvider.php:483 — clear_account( array $context ) compatibility entry point.
• inc/Abilities/AuthAbilities.php:831 — internal save via $principal_context.
• inc/Abilities/AuthAbilities.php:833 — internal save via deprecated context-style save_account().
• inc/Abilities/AuthAbilities.php:920 — manual token save via deprecated context-style save_account().

Related closed planning issue: #2117.

Why this matters

The named per-user/per-agent APIs document no-fallback semantics, but the context/policy path can still resolve to site-level credentials. That makes it too easy for callers to accidentally choose fallback behavior when they meant explicit principal scope.

Acceptance criteria

• Internal Data Machine callsites use named site/user/agent account methods instead of context-array save_account() / clear_account() calls.
• get_account_for_context() fallback behavior is explicitly decided for 1.0: either removed, renamed to indicate policy fallback, or isolated behind a clearly opt-in API.
• Deprecated context-array APIs are either removed for 1.0 or emit/route through a narrow shim with no internal callers.
• Tests cover missing scoped credentials and prove they do not silently read site credentials unless the API explicitly asks for that fallback.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (GPT-5.5)
• Used for: 1.0 technical-debt audit and issue drafting; Chris requested tracking issues for the findings.