Track config-source provenance on hdb_nodes / hdb_role for deterministic config-driven deletes

[kriszyp]

When hdb_nodes and hdb_role records are generated from configuration (harperdb-config.yaml and roles.yaml), the records carry no indication of which source created them. As a result, if an entry is removed from config, we can't safely deduce that the corresponding record should also be removed (it might have been created via the operations API, which should survive).

Ask

• Stamp config-sourced records with their provenance (e.g. a _source field with the path or origin marker).
• On config change, identify entries that were present in the prior config but are now removed; deterministically delete the corresponding records only if they have the matching config-source provenance.
• API-created records remain untouched by config-driven deletion.

Cluster wrinkle (from the Jira description)

The configuration "exists through a cluster" — multiple files on multiple nodes that may not be in sync. So a removed entry on one node doesn't necessarily mean it's removed cluster-wide. The proposed mechanism:

• Compare timestamps of records vs. timestamps of configuration changes.
• Only treat an entry as "removed by config" if the config change is recent enough to credibly explain the absence (i.e. newer than the record's creation/last-update time).

Acceptance criteria

• New config-sourced records carry source/provenance metadata.
• Config-driven removal works deterministically: removing an entry from config and reloading causes the matching record to be deleted if and only if it was config-sourced and the config change post-dates the record.
• API-created records are not affected by config reloads.

Out of scope

• The equivalent for tables / schema.graphql — different enough to warrant its own ticket (per the Jira description).

---

Tracked in Jira: CORE-2967

🤖 Filed by Claude on behalf of Kris.