hamsci_sink: sink.db lost/recreated → first-writer 644 perms brick the sink until manual chmod + restarts

[rrobinett]

Found while building the golden image from the VM101 greenfield (2026-07-25): if /var/lib/sigmond/sink.db is ever absent at boot (scrubbed image, disk repair, operator delete), whichever process touches it first recreates it with its umask — hs-uploader's 30s watermark poll usually wins and leaves -rw-r--r-- hsupload:sigmond. The recorders (group sigmond) then can't write:

• hamsci_sink.writer opens unwritable, silently buffers, and after ~400 rows every insert raises BufferFull: ... (SQLite unwritable at /var/lib/sigmond/sink.db) — decodes are lost from then on.
• The writer never re-probes writability, so even after a manual chmod 664 the services must be restarted to recover.
• Schema is also only created by the writers, so the uploader-created file is a 0-byte husk.

Suggested hardening (any one is sufficient, first is cleanest):

1. Create/verify sink.db (schema + 0664 + group sigmond) in a root-owned unit or at smd config/apply time, so writers/readers never race to create it.
2. Writers: on unwritable, retry the open on each flush instead of buffering to a terminal BufferFull.
3. All sink openers set umask/os.fchmod to 0664 on create.

Repro: stop everything, rm /var/lib/sigmond/sink.db*, reboot; watch psk-recorder BufferFull ~7 min after boot.