fix(build): pin @strapi/sdk-plugin to ^5.4.0 — v6 produces broken 23-line stub bundles

CRITICAL: the last published version (2.10.0) is unusable. The
dist/server/index.js tarball entry is only 23 lines:

    const register = require('./register');
    const bootstrap = require('./bootstrap');
    const destroy = require('./destroy');
    ...
    module.exports = { register, bootstrap, destroy, ... };

It re-exports submodules that are NOT actually in the tarball. Any
consumer installing 2.10.0 crashes immediately at strapi boot with
    Error: Cannot find module './register'

Root cause: `@strapi/sdk-plugin` v6 (pinned to 6.0.1 a few releases
ago) ships a new build pipeline that does not recursively inline
`require('./submodule')` imports from the entry point. Where v5's
pack-up would bundle the entire transitive tree into a single
dist/server/index.js, v6 leaves every first-level require() as a
bare re-export to a path that isn't in `files` or resolvable at
runtime. The result is a 23-line stub that looks healthy to
`strapi-plugin verify` (exports resolve) but is functionally a
zero-byte plugin.

Rolled @strapi/sdk-plugin back to ^5.4.0 (v5's packup-based
toolchain, which Strapi documents as still supported via
`pin to 5.x` in the v6 upgrade guide). Fresh lockfile generated with
`npm install --no-workspaces` so `npm ci` in CI resolves the same
tree.

Verified locally: the fresh bundle is 73,664 lines (all transitive
deps inline), strapi-plugin verify passes cjs/esm export resolution,
and the re-created dist/server/index.js starts with real runtime
imports (`require('crypto')`, `require('nodemailer')`, etc.) instead
of the stub `require('./register')` pattern.

After this lands, semantic-release will publish 2.10.1. The broken
2.10.0 should be `npm deprecate`d manually with a pointer to
2.10.1 so nobody installs the stub by accident.

Author: Schero94