chore: tighten EmDash core and adapter type safety

[vidarbrekke]

Summary

This pull request is a type-safety and SQL-hardening cleanup across EmDash runtime layers with no behavior changes.

Scope and intent

• Remove unsafe casting patterns in core runtime paths.
• Tighten SQL-builder and repository typing for safer dynamic field/table usage.
• Keep API and route behavior unchanged.
• Keep the change limited to EmDash runtime packages only.

Notes

• The change is intentionally narrow in behavior:
  • keeps public interfaces/contracts stable
  • preserves existing control flow and SQL logic while improving static safety
  • does not introduce external API changes

[changeset-bot]

⚠️ No Changeset found

Latest commit: 74b617b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

1 out of 2 committers have signed the CLA.
✅ (vidarbrekke)[https://github.com/vidarbrekke]
❌ @emdashbot[bot]
_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[github-actions]

Scope check

This PR touches 28 files. PRs with a broad scope are harder to review. Please confirm the scope hasn't drifted beyond the intended change.
This PR spans 4 different areas (area/core, area/plugins, area/auth, area/cloudflare). Consider breaking it into smaller, focused PRs.

If this scope is intentional, no action needed. A maintainer will review it. If not, please consider splitting this into smaller PRs.

See CONTRIBUTING.md for contribution guidelines.

[vidarbrekke]

I have read the CLA Document and I hereby sign the CLA

[github-actions]

Overlapping PRs

This PR modifies files that are also changed by other open PRs:

• fix: add siteUrl to resolve origin mismatch behind reverse proxies #382 (3 shared files)

This may cause merge conflicts or duplicated work. A maintainer will coordinate.

[ascorbic]

recheck

[github-actions]

This PR has been inactive for 14 days. It will be closed automatically in 7 days if there is no further activity.

If you're still working on this, please push an update or leave a comment.

[emdashbot]

This is a well-intentioned and mostly correct type-safety and SQL-hardening sweep. The approach fits EmDash's architecture: replacing unsafe as any/as unknown casts with narrower types, adding runtime guards where narrowing alone isn't enough, and using sql.ref() and parameterized templates instead of string-interpolated SQL. The SQL changes in content.ts and rewrite-urls.ts follow Kysely's safe patterns, and mapOrderField already whitelists order columns so sql.ref(dbField) is injection-safe.

Three gaps remain:

1. Two dangling eslint-disable-next-line @typescript-eslint/no-explicit-any comments in playground-middleware.ts were left behind after Kysely<any> was replaced with Kysely<Database>. These are likely to trigger lint diagnostics about unused disable directives.
2. No changeset was added, yet the PR changes exported types (StandardHookHandler, StandardRouteHandler, StandardPluginDefinition) and introduces new runtime validation in the WordPress plugin import route. Per AGENTS.md, published package changes require a changeset.
3. The new parseWpPluginImportConfig validation function in wordpress-plugin/execute.ts changes route behavior (invalid configs now return 400 instead of being passed through), but there are no tests covering the validation paths. AGENTS.md expects tests for new runtime behavior.

[MA2153]

Hello. This PR has been open for more than a month, yet the CLA has not been signed. If you intend to follow through, kindly open a new PR and sign the CLA. Thank you.

[MA2153]

I realize you have sent a message to sign the CLA but it seems like there are unresolved conflicts. Feel free to open a new PR either way and we are happy to take a new look.