chore: update better-auth dependencies to version 1.5.4 and refactor …

[Siumauricio]

…imports in auth-client and auth modules

What is this PR about?

Please describe in a short paragraph what this PR is about.

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance. If you have not tested it yet, please do so before submitting. This helps avoid wasting maintainers' time reviewing code that has not been verified by you.

Issues related (if applicable)

Screenshots (if applicable)

Greptile Summary

This PR graduates better-auth and its ecosystem from the 1.5.0-beta.16 pre-release to the stable 1.5.4 release, and refactors the apiKey plugin and its client counterpart to import from the new standalone @better-auth/api-key package instead of the monolithic better-auth/plugins / better-auth/client/plugins paths.

Key changes:

• better-auth, @better-auth/sso updated from 1.5.0-beta.16 → 1.5.4 in both apps/dokploy and packages/server
• @better-auth/api-key@1.5.4 added as an explicit dependency in both packages
• packages/server/src/lib/auth.ts: apiKey now imported from @better-auth/api-key
• apps/dokploy/lib/auth-client.ts: apiKeyClient now imported from @better-auth/api-key/client
• better-call bumped from 1.3.2 → 2.0.2 in packages/server — a major version jump that conflicts with the exact peer dependency (better-call: 1.3.2) declared by both @better-auth/core@1.5.4 and @better-auth/sso@1.5.4 in the lockfile, which could produce peer dependency warnings on fresh installs or fail in strict-peer-dependency CI environments

Confidence Score: 4/5

• Safe to merge with low risk — the import refactoring is correct and the stable better-auth@1.5.4 upgrade is straightforward, but the better-call major version bump should be verified against peer dependency expectations.
• All import path changes align with the new @better-auth/api-key package layout, and the underlying auth logic is unchanged. The only notable concern is the better-call 1.3.2 → 2.0.2 major version bump in packages/server while @better-auth/core@1.5.4 and @better-auth/sso@1.5.4 still declare an exact peer dependency on better-call: 1.3.2, which may surface peer dependency warnings or cause install failures in strict environments.
• packages/server/package.json — verify the better-call@2.0.2 upgrade is intentional and confirm no peer-dependency warnings are generated during pnpm install.

_{Last reviewed commit: 3042805}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

better-call major version bump may trigger peer dependency warnings

better-call is upgraded from 1.3.2 to 2.0.2 here, but both @better-auth/core@1.5.4 and @better-auth/sso@1.5.4 still declare an exact peer dependency on better-call: 1.3.2 in the lockfile:

'@better-auth/core@1.5.4':
  peerDependencies:
    better-call: 1.3.2   ← exact version, but 2.0.2 is installed

'@better-auth/sso@1.5.4':
  peerDependencies:
    better-call: 1.3.2   ← same

A major version bump (1.x → 2.x) normally signals breaking changes and falls outside semver compatibility. pnpm will likely emit peer dependency mismatch warnings on fresh installs (pnpm install), and CI environments with --strict-peer-dependencies will fail outright.

If the better-auth ecosystem intentionally moved to better-call@2.0.2 in v1.5.4, the peer dep declarations in the published packages appear to be stale/incorrect. It would be worth verifying against the official better-auth v1.5.4 release notes or issue tracker to confirm this upgrade is expected and that no peer-dep warnings are surfaced during install.