test: add config CRUD unit tests

[MD-Mushfiqur123]

Closes #391

Adds table-driven Go tests for LocalStorage config CRUD operations: SetConfig, GetConfig, ListConfigs, DeleteConfig.

10 test cases covering:

• first insert creates version 1
• upsert increments version, preserves created fields
• list returns lexical order
• get missing key returns (nil, nil)
• delete removes entry
• delete missing key returns error
• cancelled context fails fast
• delete nonexistent config twice
• list configs when empty
• multiple upsert round-trip

cd control-plane && go test ./internal/storage/... -run Config -count=1
ok  github.com/Agent-Field/agentfield/control-plane/internal/storage

PR generated by AI agent.

[CLAassistant]

All committers have signed the CLA.

[AbirAbbas]

@MD-Mushfiqur123 thank for the contribution, if you could sign the CLA agreement I can get started on the review

[santoshkumarradha]

Quick heads-up: this is going to conflict with #606. Both PRs add control-plane/internal/storage/config_storage_db_test.go for issue #391, and the newer PR covers the same CRUD surface plus cancellation/deadline paths.

Please coordinate so we keep one version of this test file. Otherwise one of the two PRs will be stale even before CLA is sorted out.

[santoshkumarradha]

Thanks for filling in config-storage coverage here. I pulled the branch locally and checked it against main, and the main issue is that this file mostly duplicates scenarios we already exercise in existing tests.

TestLocalStorageConfigLifecycle already covers the SQLite path for insert, update/version bump, lexical list order, delete, missing delete, and canceled context. We also already cover the postgres branch in coverage_storage_clinch_test.go. Adding a second full CRUD suite for the same behavior makes this area harder to maintain without giving us much new signal.

Can you tighten this down to only the cases that are genuinely missing from current coverage, or extend the existing test(s) instead of introducing a parallel suite? Once that overlap is removed, I’m happy to take another look.

[santoshkumarradha]

Most of this new file overlaps with coverage we already have on main. TestLocalStorageConfigLifecycle in local_vector_config_pubsub_test.go already exercises the SQLite config CRUD path, and coverage_storage_clinch_test.go covers the postgres branch too. Can we fold any truly missing assertions into those existing tests instead of adding a second end-to-end CRUD suite here?

[MD-Mushfiqur123]

@MD-Mushfiqur123 thank for the contribution, if you could sign the CLA agreement I can get started on the review

done

[github-actions]

📊 Coverage gate

Thresholds from .coverage-gate.toml: per-surface ≥ 84%, aggregate ≥ 85%, max per-surface regression ≤ 1.0 pp, max aggregate regression ≤ 0.50 pp.

Surface	Current	Baseline	Δ
control-plane	87.40%	87.40%	→ +0.00 pp	🟡
sdk-go	92.00%	92.00%	→ +0.00 pp	🟢
sdk-python	93.73%	93.73%	↑ +0.00 pp	🟢
sdk-typescript	90.42%	90.42%	→ +0.00 pp	🟢
web-ui	84.82%	84.79%	↑ +0.03 pp	🟡
aggregate	85.77%	85.75%	↑ +0.02 pp	🟡

✅ Gate passed

No surface regressed past the allowed threshold and the aggregate stayed above the floor.

[github-actions]

📐 Patch coverage gate

Threshold: 80% on lines this PR touches vs origin/main (from .coverage-gate.toml:thresholds.min_patch).

Surface	Touched lines	Patch coverage	Status
control-plane	0	—	➖ no changes
sdk-go	0	—	➖ no changes
sdk-python	0	—	➖ no changes
sdk-typescript	0	—	➖ no changes
web-ui	0	—	➖ no changes

✅ Patch gate passed

Every surface whose lines were touched by this PR has patch coverage at or above the threshold.