fix(semaphore): support sqlite as database.type

[fabiofilz]

I ran into this exact problem deploying to a fresh k8s environment (chart 16.2.2 / app v2.18.3). Since the app itself already supports sqlite as a valid dialect (see util/config.go: DbDriverSQLite = "sqlite"), the gap is entirely in the chart. The values.schema.json enum still only allows bolt|mysql|postgres, and more importantly templates/deployment.yaml and templates/pvc.yaml only create the persistent volume/mount for database.type == "bolt". Setting type: sqlite without a chart fix silently loses persistence (no PVC/volume is mounted at all) and also breaks templates/secret-database.yaml, which tries to b64enc an unset database.password for any non-bolt type.

I patched this by treating sqlite the same way as bolt everywhere those three files branch on database.type == "bolt" (reusing database.path for the file location, mounting the same persisted volume, and skipping the credentials Secret since file-based DBs don't need one). I also renamed the volume/PVC from boltdb to dbfile since it's no longer bolt-specific. Tested end-to-end: pod starts, logs show SQLite <name>@<path>, no more BoltDB deprecation warning.

I deliberately did NOT change the default database.type (still bolt), to avoid breaking existing installs that rely on the implicit default during a helm upgrade. Instead, I updated the docs to make sqlite the clearly recommended path going forward:

• Generalized the database.path/persistence.* field descriptions (previously worded as bolt-only) in values.yaml and the generated README.md table.
• Added a dedicated "SQLite" example section, placed ahead of the MariaDB/PostgreSQL examples.
• Added a "Migrating from BoltDB" section documenting the built-in semaphore migrate --from-boltdb command (available in v2.17/v2.18 only) and the SEMAPHORE_MIGRATE_FROM_BOLTDB env var for Kubernetes, plus a note that this tooling was removed in v2.19 and what to do if you're already past that.

Open to feedback on the approach. e.g. if you'd rather introduce a dedicated database.sqlite.path field instead of reusing database.path, or change the default, happy to rework it.

Fixes #31

[roylindauer]

Wanted to chime in and say that I was able to test this, that it works, and has unblocked me. I hope this gets merged!

About the question of database.path, rather than introducing a dedicated path, it keeps the file based backends consistent and there is no case where you would have both at once. So it seems perfectly reasonable to re-use the key for both. Leaving the default as bolt also feels correct for upgrade safety.