The init and analyze steps were pinned to 7999b86c, a commit no release tag
points at, with a "# v4" comment that names another commit (zizmor
ref-version-mismatch, two code-scanning alerts). Both steps now use
2892aa5e, the commit of v4.38.2, with that exact version as the comment.

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

The Kotlin backend checked its documentation with Dokka; the ASP.NET Core
API had only the compiler warning for a public declaration without a
comment. CI now builds the API reference with DocFX, every warning as an
error, and Documents/api/CheckDocumentation.cs fails when a namespace,
type or member of the reference has no description, internal and
private members included. The setup is the one Progmaweb uses: the
docfx tool pinned in .config/dotnet-tools.json, the configuration and
the namespace description under Documents/api, and the generated
reference ignored.

The ASP.NET Core API builds and tests the same on every host, and the
macOS runners are the queue every repository of the organization waits
in: the first run of the job was cancelled before it started.

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

The language website ran a Spring Boot application on JVM 25 for two
endpoints, and it was the only JVM on the server: a quarter of a
gigabyte of resident memory for /api/v1/site and /health. The server
already runs ASP.NET Core 10 for Progmaweb.

The API is now Progmasoft.Tala.Website.Api, a minimal ASP.NET Core 10
application under the namespace Progmasoft.Tala.Website. It answers as
before: /api/v1/site returns the site's own state as the same JSON,
POST is not allowed there, /health answers with an empty 200, and every
other path is 404. It listens on 127.0.0.1, port 5086 unless PORT says
otherwise, as the Spring process did, so Nginx is unchanged.

- Progmasoft.Tala.Website.slnx, Directory.Build.props and global.json
  set up the solution with warnings as errors, documentation comments
  required and NuGet lock files.
- Progmasoft.Tala.Website.Api.Tests runs the endpoints in an in-memory
  host with xUnit v3 on Microsoft.Testing.Platform.
- ops/systemd/tala-site-api.service runs the published DLL on the shared
  runtime from /srv/xsharp/website/current/site-api, with the hardening
  of the unit it replaces.
- CI builds, tests, publishes and reports coverage with dotnet; CodeQL
  analyzes C# instead of Kotlin; Renovate watches NuGet instead of
  Gradle.

The pages were renamed; the rest of the repository still said Visual X#:
- the site API answered with the name Visual X#, and its test expected it;
- the documents, the issue and pull request templates, the support address
  and the name of the code scanning configuration.

The documents also said that a left-to-right mark follows the name of the
language in Hebrew text. That was for the `#` of the old name; the sentence
now speaks of names that end in a symbol, such as C#.

Not changed: host names, paths and unit names on the server, the name of the
backend artifact, the Kotlin package of the backend, and the keys of the
browser storage.

The pull request that hands version updates to Renovate is folded in
here, so that the two workflow changes are tested and merged once.

Renovate proposes the version updates of this repository from now on.
It watches what Dependabot watched, looks once a week, takes a release
a week after it is published, opens one pull request for each kind of
dependency with at most two open, and rebases a pull request only when
it conflicts. A dashboard issue lists what is pending.

The Dependabot configuration is removed, which turns its version
updates off. Dependabot keeps its alerts and its security updates,
which are repository settings. Renovate does not open its own pull
requests for vulnerabilities, so one advisory does not get two fixes.

The configuration passes Renovate's validator and takes effect when
the Renovate app is installed on the repository.

ci.yml already has a dependency-review job, which I missed. The
workflow this branch added ran the same review a second time on every
pull request, so it is removed; the existing job stays as it is.

The owner decided against running OpenSSF Scorecard here. The workflow
added by the commit before this one is removed; nothing else changes.

zizmor audits the workflows themselves for what makes a workflow
unsafe, and uploads what it finds to code scanning. Its first run here
found one thing, 4 times: a checkout that leaves the job's token in
the checked-out repository, where any later step can read it. No
workflow pushes or needs the token after the checkout, so every checkout
now sets persist-credentials to false, and zizmor reports nothing.

OpenSSF Scorecard grades how the repository is kept: branch protection,
pinned dependencies, token permissions and the like. It runs on the
default branch and weekly, publishes its score and uploads its findings to
code scanning.

Dependency Review fails a pull request that adds or changes a dependency
with a known vulnerability of high severity or worse. Dependabot watches
what is already there; this holds what comes in.

Every new action is pinned to a commit, each job names the permissions
it needs, and no new workflow has a default permission.