feat: registry-listing manifest fields, screenshots, and README polish

[aesslinger]

Summary

Prepares this plugin for its eventual Tabularium registry submission. Registry publication requires an approved .tabularium manifest, hosted release assets, and a /submit flow verified via OAuth against this repo — this PR covers the manifest and README side of that; it does not submit anything. Three separate, independently-reviewable commits:

1. Registry-listing manifest fields (f8a6d4b) — .tabularium had every runtime-required field but none of the registry-listing ones every published sibling plugin has: category, tags, license, readme, homepage, documentation_url, support.issues_url, color. Confirmed these are purely presentational for the registry's plugin-card/detail page — the builtin driver's own definition (tabularis's src/hooks/useDrivers.ts) has none of them, so no version bump is warranted here. Also refreshed the README/CLAUDE.md's stale "pending sign-off" language (tabularis PR #577's checklist is now fully checked, though the PR itself is still open/unmerged) and fixed the README's release badge, which showed "no releases or repo not found" because every release so far is flagged prerelease: true and GitHub's /releases/latest API excludes those by design.

2. Real UI screenshots (a2ff1d7) — 7 real captures (not mockups), taken against a live build of this plugin (v1.0.0-beta.4) connected to an actual PostgreSQL instance: fresh install → database picker → connection form → successful test connection → saved connection card → multi-schema browsing → a data grid showing a real enum column value (sad) — that last one doubles as live proof the enum-extraction fix (issue execute_query returns null for PostgreSQL enum column values #7) actually works end-to-end. Wired into .tabularium's new screenshots array and added a matching gallery section to the README.

3. README header polish (11ae1f8) — added a plus icon between the Tabularis and PostgreSQL logos so the header reads "Tabularis + PostgreSQL" at a glance (had to be an image, not a styled text character — GitHub's README sanitizer strips inline style attributes). Also self-hosted a copy of the PostgreSQL project's 3-colors logo instead of hotlinking wiki.postgresql.org, matching why postgresql-icon.svg is already self-hosted rather than pointed at a third party.

Remaining steps before the plugin can actually reach the public registry

This PR is prep work only — merging it does not publish anything. Do not merge until the following, in order:

1. tabularis PR #577 merges. It's the sign-off vehicle for promoting this repo to the primary PostgreSQL plugin home. Every checklist item on that PR is already ✅ (security audit, CI hardening, cross-platform build, 24-item manual smoke test, full regression pass); the PR itself just hasn't merged yet.
2. Resolve the #614 fix-order conflict first, since it affects whether #577 merges cleanly. This repo's own #577 branch already carries a broader, capability-driven fix for tabularis issue #614 (identifier quoting keyed off sql_dialect, not driver id). tabularis PR #588 has a narrower, competing fix for the same root cause. Whichever merges to tabularis main second will conflict with, or silently regress, the other — someone needs to decide merge order (or reconcile the two fixes) before #577 lands.
3. Merge this PR (#18) once #577 is in, so the manifest/README changes land on main before submission.
4. Submit at https://registry.tabularis.dev/submit. Requires OAuth login against this repo's GitHub identity for ownership verification — whoever submits needs push/owner access to TabularisDB/tabularis-postgresql-plugin. The registry pre-validates the manifest via POST /api/manifest/validate; a bad manifest is rejected with HTTP 422, no silent fallback. Our .tabularium already validates clean against the live schema as of this PR.
5. Wait for manual admin approval. Every plugin currently listed on the registry (12/12, checked via /api/plugins) shows status: "approved" — this is a real human-reviewed gate, not a formality. Check /requests on the registry after submitting to track status.

Verification

• npx @tabularium/cli validate .tabularium --registry https://registry.tabularis.dev --kind driver → ok (validated after each commit)
• npx markdownlint-cli README.md CHANGELOG.md → clean
• Screenshots captured against a real v1.0.0-beta.4 build, confirmed the plugin's branded icon renders correctly in the "Choose a database" picker (surfaced a separate tabularis-side bug along the way — filed as tabularis#632 — where that same icon fails to render everywhere except the picker, due to a missing URL-handling branch in getDriverIcon)

Test plan

• Manifest validates clean against the live registry schema after every commit
• README/CHANGELOG markdownlint-clean
• Screenshots are real captures against a live build + live database, not mockups
• Do not merge until tabularis PR #577 lands (see "Remaining steps" above for the full sequence)

Versioning

CI's version-suggestion bot classifies this PR as feat:minor:beta → next tag v1.0.0-beta.5 (confirmed via its comment on this PR). That classification is correct — this genuinely adds new plugin capability (registry-listing readiness), not a fix or pure maintenance.

The version bump itself does not live in this branch. Following the pattern used for every prior release (beta.2 → .3 → .4, each its own "Bump version to X" commit made directly on main after the corresponding feature PR merged, not baked into the feature branch), .tabularium/Cargo.toml/Cargo.lock will be bumped to 1.0.0-beta.5 in a dedicated commit on main once this PR actually merges — which, per "Remaining steps" above, won't happen until tabularis PR #577 lands. Bumping the version now, while this PR is deliberately held open, would let a beta tag sit reserved on an unmerged branch indefinitely and could conflict with whatever unrelated PR merges to main first in the meantime.

[github-actions]

Version suggestion

Based on this PR's title (feat) and the prerelease:beta label:

Current	1.0.0-beta.4
Suggested next tag	v1.0.0-beta.5

This is informational only — no tag or release is created automatically yet.