extension_version.published_by_id should be NOT NULL #2266

Summary

extension_version.published_by_id (added in V1_72__Trusted_Publisher.sql) is nullable at the
schema level, and the JPA/jOOQ code that reads it (ExtensionVersionJooqRepository,
ExtensionVersion.toExtensionJson(), LocalRegistryService.isVerified(), the ExtensionJson
DTO's @NotNull annotation, the webui's Extension.publishedBy type) is inconsistent about
whether a null value is possible - some paths null-check it, several ExtensionVersionJooqRepository
queries INNER JOIN user_data on it (which would silently drop, or 404, an otherwise-valid
extension/version if it were ever null), and the webui dereferences it unguarded in two spots
(extension-detail.tsx).

Investigation

This surfaced while reviewing PR #2161 (a Copilot review comment flagged one of the affected
INNER JOINs). Two theories were checked:

1. Is a null value actually reachable today? PublishExtensionVersionHandler.java is the
   only place in the codebase that calls entityManager.persist() for a new ExtensionVersion,
   and it unconditionally sets publishedBy (line ~253) before persisting, regardless of whether
   the request was authenticated via AccessTokenAuthentication or LoggedInAuthentication
   (session-only, no token). So every future insert is guaranteed non-null.
2. Is it null in existing (historical) data? Restoring a production DB dump taken at migration
   V1_71 and migrating it to main, SELECT * FROM extension_version WHERE published_by_id IS NULL returns zero rows.

So the column can be made NOT NULL outright - no backfill needed, and every insert path already
satisfies it.

Proposed fix

• New Flyway migration: a defensive no-op UPDATE ... WHERE published_by_id IS NULL (safety net
  for any environment whose data might differ) followed by
  ALTER TABLE extension_version ALTER COLUMN published_by_id SET NOT NULL.
• Update the ExtensionVersion#publishedBy JPA mapping to @JoinColumn(nullable = false)
  (or equivalent) to match.
• Once enforced, the ExtensionJson.publishedBy @NotNull annotation and the webui's
  Extension.publishedBy: UserData (non-optional) type are both actually true, and none of
  ExtensionVersionJooqRepository's INNER JOIN user_data ON ... published_by_id call sites need
  to change to LEFT JOIN defensively - the constraint makes that unnecessary rather than
  something to work around.

Out of scope / not needed

Making the joins LEFT JOIN and guarding the two webui .publishedBy. accesses instead of adding
the constraint was considered and explicitly rejected: it would carry extra code and API surface
for a data shape the schema can (and after this fix, will) simply disallow.