Document conductor.enable.ui.serving property for headless server deployments

### The doc issue

While exploring options to deploy the Conductor server and UI as separate services (e.g., server as API-only backend + UI in its own Nginx container), I found the property `conductor.enable.ui.serving` in the source code:

**File:** `rest/src/main/java/org/conductoross/conductor/SpaInterceptor.java`

```java
@ConditionalOnProperty(
value = "conductor.enable.ui.serving",
havingValue = "true",
matchIfMissing = true
)
```

Setting `conductor.enable.ui.serving=false` disables the SPA interceptor, effectively turning the server into an API-only instance. This is useful for production setups where you want to scale server and UI independently.

However, this property does not appear in:
- The official documentation at https://docs.conductor-oss.org
- The configuration reference
- Any of the example property files (`config-redis.properties`, `config-postgres.properties`, etc.)
- The README

---

### Suggest a potential alternative/fix

1. Add `conductor.enable.ui.serving` to the configuration reference documentation on https://docs.conductor-oss.org with a description of its behavior and default value.
2. Include a section in the deployment guide about running server and UI as separate services (a common production pattern).
3. Add a commented example in the default property files shipped with the Docker image:
`# conductor.enable.ui.serving=false`
4. Clarify if this is the recommended approach or if there's a preferred alternative.

Start with rest/src/main/java/org/conductoross/conductor/SpaInterceptor.java and verify the property's behavior and default value. Then update the configuration reference and deployment guide, and consider the named config-redis.properties and config-postgres.properties examples. Done means the API-only setting, separate server/UI deployment pattern, default, and recommended approach are documented clearly.

Written by the indexing model from the issue text.