revert(perf): drop the dockerode and docker-modem pnpm patches

Both patches came out of this work and both are removed at the maintainer's
request. The finding was real - ssh2's WASM heap costs +14.0 MiB RSS on require,
and @grpc/grpc-js another 14.6 MiB across 61 files, neither of which a
socket-based Docker install ever uses - but patching a dependency means every
future dockerode or docker-modem bump fails until someone regenerates the patch,
and that recurring cost is not worth roughly 25 MiB.

The finding stays on record in SERVER-MEMORY.md because the fix belongs upstream:
both packages require a module at file scope while using it in exactly one
already-guarded branch, so a PR to each would fix it for every consumer with no
patch to maintain here.

The two remaining patches, @types/node-unifi and trpc-to-openapi, predate this
work and are untouched. allowUnusedPatches was already set on dev and is left
alone. Lockfile regenerated: patchedDependencies now lists only those two.

Also sharpens the Cache Components entry. The SqliteError was simply an unmigrated
build database, which is fixable - but feeding the build a database would be the
wrong fix, because serverSetting is per-installation data on the user's volume and
a shell prerendered against the build machine's database would bake one install's
settings into every other install's first paint. The error was Next.js correctly
reporting a request-time read sitting in the shell path.

docs/perf/REJECTED.md

@@ -31,12 +31,21 @@ const [session, user, serverSettings, colorScheme] = await Promise.all([
 ]);
 ```
 
-For a self-hosted app whose database is created at runtime on the user's volume, there is nothing to
-query during a build. Fixing it means deferring those reads into `<Suspense>` — but all four feed
-providers that wrap `children` (`AuthProvider session=`, `SettingsProvider user=`), so deferring them
-puts essentially the whole app inside the boundary and leaves a static shell of little more than
-`<html><body>`. The build would report `◐` while shipping an empty shell, which is precisely the
-failure the migration guide warns about.
+The immediate cause is mundane: no migration had been run, so the build had no tables. That is fixable
+— run the migration first and the build gets a database.
+
+**But making the error go away that way would be the wrong fix, and the error is the useful signal.**
+If a build needs the database in order to prerender a route, the route's content is being decided at
+build time rather than per request. For Homarr that is actively wrong: `serverSetting` is
+per-installation data on the user's own volume, so a shell prerendered against the build machine's
+database would bake one install's settings into every other install's first paint. The error is Next.js
+correctly reporting that a request-time read sits in the shell path.
+
+The honest fix is therefore to defer those reads into `<Suspense>`, not to feed the build a database.
+And that is where it stops being worth it: all four values feed providers that wrap `children`
+(`AuthProvider session=`, `SettingsProvider user=`), so deferring them puts essentially the whole app
+inside the boundary and leaves a static shell of little more than `<html><body>`. The build would
+report `◐` while shipping an empty shell — precisely the failure the migration guide warns about.
 
 **And the prize is small.** Measured against a running container, warm, five repeats: