DriverRegistry is dead code, and it disagrees with the live provider map

app/Services/Social/DriverRegistry.ts exports getSocialDriver() and listSocialDrivers(). Nothing calls either one, and the list it would return is wrong.

Evidence

Zero references to the module anywhere in the repo:

grep -rn "DriverRegistry" --include="*.ts" --include="*.stx" .   # (excluding node_modules)
-> no matches
grep -rn "getSocialDriver\|listSocialDrivers" app/ --include="*.ts" | grep -v DriverRegistry.ts
-> no matches

Ruled out dynamic loading too: the only import( calls under app/ that mention social are type-only import('@stacksjs/socials') positions in app/Support/Social/types.ts, and the only other occurrences of "Registry" in the tree are CommandRegistry and StackExtensionRegistry. Moving the file out of the tree changes nothing that resolves.

Why it is worse than ordinary dead code

It is the file you would open to answer "which providers can Postline publish to", and it answers five:

// DriverRegistry.ts - dead
const drivers = { bluesky, twitter, linkedin, instagram, threads }

The live dispatch is a second map in CrosspostService.ts, and it answers seven:

// CrosspostService.ts - load-bearing
const publishers = { bluesky, twitter, linkedin, instagram, threads, mastodon, blog }
export function crosspostProviders(): SocialProvider[] { return Object.keys(publishers) }

So the dead registry silently omits mastodon and blog. MastodonDriver.ts exists, has its own unit test, and is reached through MastodonService - just never through the registry. A reader checking the registry concludes Mastodon is unsupported, and getSocialDriver('mastodon') would throw Social driver "mastodon" is not installed yet. if anything ever called it.

This is the same shape as stacksjs/stacks#2539 / #2489: the primitive is fine, one caller never reaches it, so nothing fails.

Fix

Delete DriverRegistry.ts, and keep crosspostProviders() as the single answer to "which providers exist". Or, if the registry is meant to be the seam, make CrosspostService build publishers from it so the two cannot drift again - but it has to be one or the other, not both.

Either way, add a test that pins crosspostProviders() against the Drivers/ directory listing so a new driver that is never wired up fails rather than going quiet.

Noticed while auditing #40 - that issue's description claims the drivers are "wired through DriverRegistry and CrosspostService", which is the wrong half of this. Correcting it there.