The documentation check of CI requires a comment on every API item and
a page for every namespace; 38 items of Progmasoft.OAuth had none. The
private handlers and helpers get summaries, MemoryOAuthDatabase its
field, and docs/api/namespaces describes Progmasoft.OAuth and its
Developers, Endpoints, Pages and Storage namespaces.

Verified: dotnet build in Release, dotnet docfx with warnings as
errors, and CheckDocumentation: all 353 API items are documented.

pnpm audit reports a critical advisory for next >=16.0.0 <=16.4.0:
unauthenticated remote code execution through the Image Optimization
API when SVG files are used. progmasoft.com runs 16.3.8. The site sets
no images option and the optimizer refused an SVG request in a check
from outside, but the version is in the affected range, so it moves to
16.4.2, the latest patch release; eslint-config-next follows.

Verified: pnpm check, pnpm test:coverage, pnpm lint and pnpm build
pass; pnpm audit --audit-level high reports nothing beyond the one
advisory already ignored.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Progmasoft accounts can now sign in to any application, and any
developer can register one. The provider runs in the account API under
the Progmasoft.OAuth namespaces and answers on credentials.progmasoft.com.

Protocol: OpenIddict 7 (Apache-2.0) with its Entity Framework stores.
Authorization code with PKCE for every client, S256 only; refresh
tokens with rotation and no reuse leeway, so a replayed refresh token
revokes its chain; client credentials for confidential clients, without
account scopes. No implicit or password grant. Codes live 2 minutes,
access and identity tokens 15 minutes, refresh tokens 30 days. Signing
(RSA) and encryption keys are read from files in production and are
required there; other environments make keys per process.

Scopes, one grant each, as the consent page lists them: profile (the
account name), email (the sign-in address; email_verified is false,
since registration does not verify it), viget.packages.read,
viget.packages.publish and viget.packages.yank (access tokens for the
viget audience), and offline_access.

Pages, plain HTML without script, behind a content security policy that
allows the one stylesheet by digest: sign-in with the account password
(a cookie of its own, no account-site session), consent with the
application, its registering account and the return host, the developer
portal (register confidential or public clients, redirect address rules
from RFC 8252, scopes, client credentials, secret shown once and
rotatable, delete; 10 applications per account; other accounts'
applications are absent), and the applications an account has allowed,
with withdrawal that revokes their tokens. Forms carry antiforgery
tokens; return addresses stay on the host.

Storage: the oauth_* tables in the account database, created by a
numbered schema step like the account tables; the step is the script
Entity Framework generates for the model, and a test compares the two.
With the memory account store they live in a shared in-memory SQLite
database, which runs the bulk revocations the in-memory provider cannot.

A host filter keeps OAuth paths on the OAuth host and everything but
OAuth and /health off it. AllowedHosts names the new host, and a rate
limit policy covers the protocol endpoints and the portal. The Nginx
vhost for the host and the key set-up are in ops; docs/OAUTH.md is the
developer guide.

AccountService gains VerifyPasswordAsync, which LoginAsync now uses,
and FindAsync.

Verified: dotnet build with warnings as errors; dotnet test, 125 tests,
109 passed and 16 PostgreSQL tests skipped locally (CI runs them,
including a new one for the schema and refresh token chain revocation):
code flow with PKCE and the claims of each scope, single-use codes,
refresh rotation and reuse refusal, consent reuse and withdrawal, deny,
public client with a private-use scheme, client credentials, ViGet
audience by introspection, refusal without PKCE, of other flows and of
unpermitted scopes, unregistered redirect addresses, sign-in redirects
and prompt=none, the portal's address rules and ownership, secret
rotation, the page security policy, the host filter and the discovery
document.

BIMI lets mail clients show a sender's logo next to messages from a
domain whose DMARC policy is enforced; progmasoft.com already publishes
p=quarantine with pct=100. The BIMI record points at an SVG on the
domain, so the site now serves one at /bimi/logo.svg.

The file is SVG Tiny Portable/Secure, as BIMI requires: version 1.2,
baseProfile tiny-ps, a title, no scripts, no external references and
no x or y on the root. It draws the same four tiles as the Brand
component, in the same colours (#3b4658, #1e7188, #7655fa, #dc7644)
and the same tile-to-gap ratio (11:2, here 132 and 24 on a 512 grid),
on a white square. The mark stays inside the circle that clients crop
the logo to.

Next.js serves files from apps/web/public before the dynamic routes;
the deployment already copies public/ next to the standalone server.

A failed Google callback has returned the visitor to /login?google=failed
since the previous release, but nothing recorded why: a declined consent,
an expired or missing state cookie and a forged request all looked the
same, and the log of the service held no entry at all.

GoogleSignInFailure now handles OnRemoteFailure. It writes one warning,
event GoogleSignInFailed (id 5), with the cause: the error code Google
reported, such as access_denied, or the reason the handler refused the
callback, such as "The oauth state was missing or invalid." An error code
is written only when it is a short run of letters, digits, '_', '-' and
'.'; anything else from the query string is written as an unrecognized
error. The authorization code, the state and tokens are never logged.
The redirect is unchanged.

Four new tests cover the entry, the redirect, an unusual error value and
a refused state. The account API document describes the log entry.

A session of a Progmasoft Account, whether opened with a password or with
Google, lasted 12 hours from the sign-in, and the setting could not raise
it beyond 7 days. Sessions now last 30 days by default, and
AccountSessions:LifetimeHours may set anything from 1 hour up to that new
maximum of 720 hours; a value outside the range is clamped to it, as
before.

The lifetime stays fixed from the sign-in; it is not extended by use. The
production environment file sets no lifetime, so the new default applies
there once the API is deployed. Sessions opened before keep the expiry
they were given.

New tests check the 30-day default and the clamping of 0, 12, 720 and
10 000 hours. The account API document gives the new default and range.

A Google callback that could not finish ended in an unhandled 500: a
visitor who declined on Google's consent screen, a callback whose state
cookie had expired, and a direct request to the callback path all got an
empty error page. The account API document already promised a redirect
to /login?google=failed for a failed callback; the handler of the Google
scheme now does that through OnRemoteFailure. Three new tests cover a
callback without state, a declined consent and a forged state.

Three statements no longer matched the sites:

- the bug report template still named the catalog paths without the
  language and the build system; they are /langs/tala/<Publisher>/<Name>/
  and /dslplugins/tazel/<Publisher>/<Name>/;
- the operations guide placed Tala content on xsharp-lang.xyz, which only
  redirects to tala.run now;
- the architecture guide described the ViGet routing before the catalogs
  per language and build system: it now gives the rewrites of /langs/tala
  and /dslplugins/tazel, the redirects of /langs and /dslplugins, three
  indexed ViGet pages and a sitemap with the home page and both catalogs.

.com has no HSTS requirement of its own, but progmasoft.com is served as
if it had one:

- Every HTTPS server block of progmasoft.com, www, account and viget
  sends max-age=63072000; includeSubDomains; preload. The www redirect
  sent none before.
- Plain HTTP only answers the ACME challenge and otherwise redirects to
  HTTPS, now with a permanent 308 instead of 301.
- The API's own HSTS policy, which it adds to HTTPS responses outside
  development, carries the same values, so a proxied response never
  shows two different policies. A test checks the header.