feat: Add optional SQLite persistence

[Copilot]

• Add Microsoft.EntityFrameworkCore.Sqlite NuGet package to DevOidcToolkit.csproj
• Add DatabaseConfiguration class with optional SqliteFile property to Configuration.cs
• Update Program.cs to conditionally use SQLite or InMemory based on Database.SqliteFile config
• Use SqliteConnectionStringBuilder for safe connection string construction
• Call EnsureCreated() when SQLite is configured so schema is created on first run
• Make user and client seeding idempotent (skip if already exists) to support restarts
• Document Database.SqliteFile in environment variable reference table in configuration.md
• Add Database to root JSON properties table in configuration.md
• Add #### Database section explaining in-memory vs SQLite, limitations (no migrations), and SqliteFile property
• Add two example JSON configs showing in-memory and SQLite modes
• Update runtime-management.md persistence note to link to SQLite config docs
• Update ARCHITECTURE.md to describe the optional persistence model
• Update CHANGELOG.md with the new SQLite persistence entry under [Unreleased]

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Feature] Persistence through a SQLite database</issue_title>
<issue_description>### Feature description

It would be good if there was an option to add persistence, currently everything is stored in memory, but a SQLite database to persist things would be nice as a configurable setting.

Would basically require some config for setting a SQLite file to save to, and then updating this conditionally based on that:

dev-oidc-toolkit/DevOidcToolkit/Program.cs

Lines 31 to 35 in 498cce8

	builder.Services.AddDbContext<DevOidcToolkitContext>(options =>
	{
	options.UseInMemoryDatabase("dev-auth");
	options.UseOpenIddict();
	});

Motivation

From #13 and #15, any changes made at runtime in the UI are wiped on restart.

Alternatives considered

Could do other database providers, but SQLite is well supported in dotnet, is simple and lightweight, and works well with Entity Framework.</issue_description>

<agent_instructions>Please make it configurable and backwards compatible.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes [Feature] Persistence through a SQLite database #20

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[jthomperoo]

This needs documentation. Explaining how to configure it, and the limitations of it (no migrations etc) and default behaviours. This should clearly explain how to set up in memory Vs sqlite dB.

[Copilot]

This needs documentation. Explaining how to configure it, and the limitations of it (no migrations etc) and default behaviours. This should clearly explain how to set up in memory Vs sqlite dB.

Done in c6d23a2. The following documentation was added:

• configuration.md — DevOidcToolkit__Database__SqliteFile added to the env var reference table; Database added to the root JSON properties table; a new #### Database section explains in-memory vs SQLite behaviour, the no-migrations limitation, and the SqliteFile property; the example JSON section now shows both the in-memory (default) and SQLite configurations side-by-side.
• runtime-management.md — the "No Persistence" note is updated to explain the default is in-memory and links to the new Database config section.
• ARCHITECTURE.md — updated to describe the optional persistence model instead of stating everything is always in-memory.

[jthomperoo]

The changelog needs updated. How does this work if I start with a sqlite dB, stop, and start again?

[Copilot]

The changelog needs updated. How does this work if I start with a sqlite dB, stop, and start again?

Changelog updated in ef9fc38.

On the restart behaviour: when you stop and start again with the same SqliteFile path, the database file is still on disk. On startup EnsureCreated() is called — this is a no-op if the schema already exists — and then the seeding runs: any users/clients already in the database are skipped (idempotent check), so config-seeded entries are not duplicated. Any users or clients you created at runtime through the UI are preserved in the file and available immediately after restart.