With an empty Google client identifier or secret the API answered every
request with 500, including registration, password sign-in and the status
route. The Google scheme was always registered, and the authentication
middleware initializes every remote scheme for each request; with empty
credentials the validation of the Google options threw there, before any
endpoint ran. The API could not be started locally without credentials, and
the "Google sign-in is unavailable" answer of the start endpoint was never
reached.

The Google scheme is now registered only when both values are configured.
Without it the service runs normally, the start endpoint answers 503, the
completion endpoint redirects to the failed sign-in page without a session,
and the callback path is not a route. With both values nothing changes.

The test factory passes the two values as host settings. The program makes
the decision while it registers services, and configuration sources a test
factory adds are applied only when the host is built, after that point.

New tests run the service without a Google client: the ordinary routes,
a full register, sign-out and sign-in round trip, and the three Google
paths. They failed with 500 against the previous program and pass now, also
when the environment of the test run carries Google credentials.

The guides no longer list this as a limitation or ask for placeholder
credentials.

Deploying this change restarts the API, which deletes every account while
the store is in memory.

The guides merged from main still said that the DocFX gate does not require
documentation comments. With this branch it does, so:

- docs/DEVELOPMENT.md and README.md list the coverage check next to the
  DocFX command and say what fails the gate.
- docs/LIMITATIONS.md no longer lists missing documentation comments as a
  limitation.

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

The DocFX gate only failed on a broken link or an unresolved reference.
DocFX does not report a declaration without a comment, and the API had
none, so the gate passed over a reference with no descriptions at all.

The gate now has three parts:

- DocFX still builds the reference with warnings as errors.
- The API project compiles its XML documentation. With warnings as errors
  already on, an undocumented public declaration or a wrong cref now fails
  the build.
- docs/api/CheckDocumentation.cs reads the metadata DocFX generated and
  fails when a namespace, type or member has no summary. This covers
  internal and private members, which the compiler does not check. It runs
  as a file-based .NET program, so the gate needs no tool beyond the SDK.
  It refuses to pass when the metadata is missing or defines nothing.

To satisfy the gate, every declaration of apps/api has documentation
comments, 131 reference items in all, and the two namespaces are described
by overwrite files in docs/api/namespaces. Only comment lines were added to
the C# sources; no statement changed.

docs/api/filterConfig.yml leaves generator-written code out of the
reference: the generated regular-expression namespace, and the one partial
method whose generated half replaces the comment of its declaration.

Verified locally: the solution builds with no warnings, the 23 API tests
pass, DocFX builds with no warnings and the coverage check passes. Removing
one summary and one namespace file made the check fail and name both.

The repository had a README and two operations notes. This adds the
documents a contributor or operator needs and corrects what had gone stale.

New, under docs/:
- README.md: index of the documentation.
- ARCHITECTURE.md: the two processes, the three hosts, the host-aware
  routing rules, the account flow and the trust boundaries.
- ACCOUNT-API.md: every endpoint with its request, responses and errors,
  the field rules, the Google flow outcome by outcome, cookies, limits and
  configuration. The responses were checked against a locally running API.
- LOCALIZATION.md: the four languages, how a page picks one, the cookie,
  how Hebrew text is laid out, and how to add a language.
- DEVELOPMENT.md: requirements, local setup, checks, tests, what each CI
  workflow enforces, the audit exception and the DocFX project.
- LIMITATIONS.md: what is missing or temporary, with the consequence of
  each: the in-memory account store, unverified addresses, no mail, no
  password change, the ignored returnTo parameter, the legacy ViGet status
  route, and that the API answers 500 to everything while the Google
  settings are empty.

Updated:
- README.md: languages, a documentation section, the local API command
  with its port, and the DocFX check.
- ops/README.md: restarting the API deletes every account, how to release
  a frontend-only change without that restart, and lessons from past
  releases.
- ops/mail/README.md: a status note that the API does not send mail yet.
- The pull request template names all four languages.

No source file changes.

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

The backend workflow now builds the API reference with DocFX and treats
every warning as an error, so an unresolved reference or a broken link
fails the check.

- docs/api holds the DocFX project: it reads apps/api/Progmaweb.Api.csproj
  and includes internal members, because the service is an application and
  most of its types are internal.
- .config/dotnet-tools.json pins docfx 2.81.0, so CI and a local run use the
  same version through `dotnet tool restore`.
- The workflow also runs when the DocFX project or the tool manifest change.
- `just api-docs` runs the same two commands locally.
- The generated site and metadata are ignored.

The gate does not require documentation comments: the API has none yet, and
DocFX does not report an undocumented member. Requiring them is a separate
change to the C# sources.

Verified locally with docfx 2.81.0 on the .NET 10 SDK: the build passes with
no warnings, and a broken link in the overview page makes it fail.

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