fix: avoid unnecessary writes to system metadata repository

[ufizo]

When running the server in a secondary, read-only role against a PostgreSQL read-only replica, the bootstrap process currently attempts to unconditionally write the media location to the metadata repository. This leads to the following error:

PostgresError: cannot execute INSERT in a read-only transaction

This PR updates the bootstrap logic to avoid unnecessary writes by writing MediaLocation only if it is missing or has changed compared to the current runtime-detected value.

This change make the bootstrap process safe to run in read-only environments.

How Has This Been Tested?

• Tested the change inside a docker container
• Compiled the changed file

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in the PR.
• I have confirmed that any new dependencies are strictly necessary.
• I have written tests for new code (if applicable)
• I have followed naming conventions/patterns in the surrounding code
• All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
• All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)

[bo0tzz]

Even with this workaround, there are plenty of other occasions where the server will try to write to the database, so I'm not sure this is the way to go for read replica support?

[ufizo]

You're right — the server may attempt writes in other places as well. However, this particular write is currently the only one that prevents the server from starting when connected to a read-only PostgreSQL replica.

I've been running globally distributed deployments where servers are split between handling read and write API calls, using read replicas for read-only servers. In practice, any failed write attempts from the read-only servers are harmless, since updates from the primary node propagate to the replica shortly after.

To clarify: this PR is not intended to provide full read-replica support, but simply to allow the server to successfully boot in read-only environments.

[mertalev]

We don't promise supporting readonly setups, so even with this fix, there could be another change in the future that breaks this setup again. Regardless, avoiding a redundant write is a good change on its own.