fix: apply preload libs and query tuning in CLI local-install

Closes #774 (closed)

dblab local-install built a projection with only databaseConfigs.configs.shared_buffers. The proposed shared_preload_libraries and probed query-tuning parameters were printed in the preview but never applied, so clones of CLI-installed instances ran with an empty shared_preload_libraries and pg_stat_statements did not work. UI Simple mode applied the full set.

Changes in engine/cmd/cli/commands/localinstall/:

• databaseConfigs builds the same databaseConfigs.configs block the UI writes: probed tuning params, shared_buffers (explicit --shared-buffers still wins), shared_preload_libraries
• empty configs block is not written
• the preview renders from databaseConfigs, the same map buildProjection applies. It previously read the proposal directly, so --shared-buffers 8GB showed the probed 4GB and then applied 8GB
• new --shared-preload-libraries flag. The CLI now writes that key, and a source loading libraries the chosen image does not ship (rdsutils, pg_cron, timescaledb) would otherwise leave the clone container unable to start with no way to correct it. The UI form has always allowed editing the value

Key-set parity with the UI is exact. One value differs by design: for an SE image the UI prefers the image's pg_config_presets.shared_preload_libraries over the probed value (SimpleMode/index.tsx:75-76), while the CLI uses the probed value, since ProposedConfig.SharedPreloadLibraries is always ResolvePreloadLibs(sourceLibs) and the engine does not read image presets. --shared-preload-libraries is the override until that resolution moves engine-side.

Tests: sample proposal carries query tuning, projection tests assert the new keys, table test covers overrides, precedence, and the empty case; preview tests assert the overridden values are the ones shown and that reserved keys alone do not open an empty tuning section; the probe whitelist is guarded against the two separately-written keys.