lex: update bsky schemas to have actual record refs, not 'unknown'

[bnewbold]

This certainly makes more sense to me for things like the "view" types, where we definitely know the type that is going to appear.

As a general style things, feels like we could use an "empty open union" in more cases where we are indicating a record?

[mary-ext]

I believe the TypeScript lex-cli is currently not set up around refs linking to records, app.bsky.feed.post would be linked as AppBskyFeedPost.Main (which doesn't exist), rather than AppBskyFeedPost.Record

we don't check the refs when generating them (so it's also possible to reference nonexistent defs)

atproto/packages/lex-cli/src/codegen/lex-gen.ts

Lines 452 to 470 in 556c5a5

	export function refToType(
	ref: string,
	baseNsid: string,
	imports: Set<string>,
	): string {
	// TODO: import external types!
	let [refBase, refHash] = ref.split('#')
	refBase = stripScheme(refBase)
	if (!refHash) refHash = 'main'
	// internal
	if (!refBase || baseNsid === refBase) {
	return toTitleCase(refHash)
	}
	// external
	imports.add(refBase)
	return `${toTitleCase(refBase)}.${toTitleCase(refHash)}`
	}

[bnewbold]

Talked to @pfrazee some more about this, and to some degree it is about keeping the schemas flexible. We could in theory end up with a "app.bsky.feed.postV2" (or "app.bsky.feed.post.v2" or whatever) iterated record type, and might want to pass that back in the existing view APIs. We could also iterate on the view API overall. My take is that this would be better served with either an open union (instead of "unknown"), and probably add a "view v2" endpoint which supports records of either type. AKA, make the future view APIs backwards compatible, instead of trying to make current view API forwards-compatible. I suspect plenty of folks have implemented clients in ways such that a different record type showing up in a "post view" would result in an error.