chore: drop the A6 rollback tombstones

A6 deployed cleanly and the provider keys are gone from the production `.env`,
which makes the legacy collector inert regardless of any settings row. The two
tombstones migration 029 pinned have no remaining job, and nothing in the
codebase reads either key.

Migration 030 deletes them and drops the Admin filter that hid them. Unlike
029's, its downgrade is meaningful — it restores both rows at their safe values,
since going back past this revision means going back toward code that reads them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/fundamentals-deployment.md

@@ -180,21 +180,6 @@ WHERE dimension = 'fundamental'
 GROUP BY dimension, is_stale;
 ```
 
-### Retired settings rows (delete later)
-
-Migration `029` pinned two SystemSetting rows as rollback tombstones rather than
-deleting them, because migrations run before the service restarts and a
-rolled-back pre-A6 process reads an absent `job_..._enabled` row as *enabled*:
-
-| key | pinned value |
-|---|---|
-| `fundamental_data_sec_dolt_cutover_enabled` | `true` |
-| `job_fundamental_collector_enabled` | `false` |
-
-Neither controls anything now; Admin -> Settings hides both. Once the A6
-rollback window has closed, delete the rows and the `MANAGED_SETTINGS` filter in
-`frontend/src/components/admin/SettingsForm.tsx`.
-
 ## Failure and rollback
 
 - **There is no provider fallback any more, and no Admin switch that freezes the