🧹 chore: Drop legacy facets table from storage schemas

[yeazelm]

Summary

• Follow-up cleanup to 🧹 chore: Remove facets system and analytics UI #155, which removed the facets/AI Insights feature from tapes deck but left the facets table behind in both the SQLite and Postgres baseline migrations
• Strip the CREATE TABLE facets (and its unique index) from pkg/storage/sqlite/migrations/001_baseline_schema.sql and pkg/storage/postgres/migrations/001_baseline_schema.sql so new databases never create
  the table
• Add a post-Migrate() cleanup on each driver (dropEmptyFacetsTable) that drops a pre-existing facets table only when it exists and is empty — databases that still hold captured facet rows are left
  untouched

Test plan

• New Ginkgo specs in pkg/storage/sqlite/legacy_facets_test.go cover all three cases: fresh DB has no facets table, pre-existing empty table gets dropped, pre-existing populated table is preserved (row
  count verified)
• Mirrored Ginkgo specs in pkg/storage/postgres/legacy_facets_test.go, gated on TAPES_TEST_POSTGRES_DSN like the rest of the postgres suite
• make format clean
• make unit-test passes (all suites green; postgres legacy specs skip without TAPES_TEST_POSTGRES_DSN, as expected)
• Manual: point an existing SQLite DB with leftover empty facets at this build and confirm the table is dropped on next startup
• Manual: run the postgres legacy specs against a real Postgres with TAPES_TEST_POSTGRES_DSN set

[jpmcb]

Ahh good catch: I think this table is abit of technical debt that we never did anything with when we had the direct deck TUI --> database client (which should have been a materialized view from an API to begin with).

I'm of 2 thoughts:

1. we could completely drop CREATE TABLE IF NOT EXISTS facets and not attempt to clean it up (which would be leaving abit of cruft around for very very early adopters but honestly probably not worth too much backwards compatibility woes)

2. we write a new migrations/002_...sql to correctly handle non-breaking backwards migrations: we do have the mechanism in place to automatically apply new migrations with an embedded filesystem pointed at the migrations/...sql files

tapes/pkg/storage/sqlite/sqlite.go

Lines 21 to 22 in 3bd28e4

	//go:embed migrations/*.sql
	var migrationsFS embed.FS

When the migrations are applied, all the .sql files get applied in order. So, I think all you'd need to do is add a new 002_drop_facets.sql

-- 002_drop_facets: removes unused facets table
-- this table was technical debt and unneeded

DROP TABLE IF NOT EXISTS facets

That way, we don't have to have bespoke code paths in Go that act as their own migration handlers/checks.

[yeazelm]

I started off a bit more conservative in case there was something I missed in the clean up but I think we can just stop creating the table and leave the table for early installs. This allows us to avoid carrying the notion of the table forward which is probably the right call if it wasn't widely used.