Move all property default values from ApplicationProperties to application-bytechef.yml

> *This was generated by AI during triage.*

## Problem

Default values for `bytechef.*` properties are currently declared in **two** places that are free to disagree:

1. Java field initialisers in `server/libs/config/app-config/src/main/java/com/bytechef/config/ApplicationProperties.java`
2. YAML in `server/apps/server-app/src/main/resources/config/application-bytechef.yml`

`@ConfigurationProperties(prefix = "bytechef", ignoreUnknownFields = false)` keeps the two *structurally* in sync (an unknown YAML key fails the bind), but nothing keeps the *values* in sync. They have already drifted.

### Confirmed drift

| Property | Java default | `application-bytechef.yml` | Note |
| --- | --- | --- | --- |
| `bytechef.message-broker.provider` | `Provider.JMS` (`ApplicationProperties.java:3649`) | `memory` | The YAML comment right above it even says *"default: memory"*. The Java default contradicts the documented default. |
| `bytechef.file-storage.filesystem.basedir` | `""` (`:3264`) | `${user.home}/bytechef/data/file-storage` | The Java default is not a usable path. |
| `bytechef.discovery-service.provider` | `Provider.REDIS` (`:3164`) | *absent* | Only reachable via the Java default; invisible to anyone reading the config file. |

### Literal duplication

Values that are stated identically in both places, and so must be edited twice forever — e.g. `bytechef.edition` (`EE`), `bytechef.ai.memory.provider` (`jdbc`), `bytechef.ai.firecrawl.base-url` (`https://api.firecrawl.dev/v2`), `bytechef.cache.provider` (`caffeine`), `bytechef.coordinator.trigger.polling.check-period` (`5`), `bytechef.tenant.mode` (`single`), `bytechef.scheduler.provider` (`quartz`), `bytechef.sign-up.enabled`, `bytechef.upgrade.enabled`, `bytechef.workflow.output-storage.provider`, `bytechef.workflow.repository.jdbc.enabled`.

### Java-only defaults

~20 defaults exist **only** as Java initialisers and appear in no YAML file, so an operator reading `application-bytechef.yml` cannot discover them:

`bytechef.feature-flags`, `bytechef.cloud.provider`, `bytechef.coordinator.enabled`, `bytechef.coordinator.task.subscriptions.*` (6 counters), `bytechef.coordinator.trigger.subscriptions.*` (6 counters), `bytechef.worker.enabled`, `bytechef.discovery-service.provider`, `bytechef.rabbitmq.port` (5672), `bytechef.redis.port` (6379), `bytechef.ai.knowledge-base.ocr.provider`, `bytechef.ai.knowledge-base.subscriptions.*` (2), `bytechef.ai.memory.aws.bucket-prefix`, `bytechef.ai.memory.aws.key-prefix`.

### Two further copies of the same constants

`application-bytechef.yml` is not the only YAML declaring these values:

- `server/ee/apps/config-server-app/src/main/resources/config/apps/application.yml` — the shared config the EE microservices pull from. Re-declares `edition`, `encryption.provider`, `file-storage.*`, `tenant.mode`, `scheduler.provider`, `data-storage.provider`, `workflow.output-storage.provider`, plus an EE-appropriate `cache.provider: redis` and `message-broker.provider: redis`.
- `server/ee/apps/runtime-job-app/src/main/resources/config/application.yml` — a third copy (`edition`, `cache.provider`, `encryption.provider`, `file-storage.provider`, `mail.port`, `message-broker.provider`, `workflow.output-storage.provider`, …), some values deliberately different (`data-storage.provider: filesystem`).

The config-server copy also still carries `bytechef.ai.openai.chat.options.model: gpt-4o`, a path that no longer exists on `ApplicationProperties` (it is now `bytechef.ai.provider.chat.openAi.options.model`). Under `ignoreUnknownFields = false` this looks like it would fail EE binding — **worth verifying at runtime as part of this work**, it may be a live EE boot bug rather than just dead config.

## Goal

One source of truth: `application-bytechef.yml` states every `bytechef.*` default; `ApplicationProperties.java` declares only *shape* (types, nesting, enums, Javadoc) and holds no constant values.

## Proposed approach

1. **Inventory.** Extract every field initialiser in `ApplicationProperties.java` that is not `= new X()` (there are ~43) and map it to its kebab-case property path.
2. **Reconcile.** For each of the three confirmed drifts, decide which value is correct and record the decision in the commit message. `message-broker.provider` in particular: the shipped default is `memory`, so `Provider.JMS` should go.
3. **Move.** Write every default into `application-bytechef.yml` (keeping the file's existing alphabetical-ish grouping and its explanatory comments), then strip the initialiser from the Java field.
4. **Align the EE copies.** Update `config-server-app/config/apps/application.yml` and `runtime-job-app/config/application.yml` so no `bytechef.*` value is inherited from a now-absent Java default. Fix the stale `bytechef.ai.openai.*` path.
5. **Guard.** Add a test that fails if a `bytechef.*` field in `ApplicationProperties` carries an initialiser (excluding `= new X()` nested-holder allocations). Without this the drift returns within a release or two.

## Hazards — read before starting

- **Primitives have no "unset".** Removing `private boolean enabled = true;` does *not* make the property required — it becomes `false`. `bytechef.coordinator.enabled`, `bytechef.worker.enabled`, `bytechef.upgrade.enabled`, `bytechef.sign-up.enabled`, `bytechef.workflow.repository.jdbc.enabled` and all thirteen `int` subscription counters will silently flip to `false`/`0` for any context whose YAML does not set them. **Every** moved primitive must be present in every YAML that a running app loads.
- **Enum-typed fields become `null`,** not a sensible fallback. Any `switch` on `getProvider()` will NPE rather than take a default branch. Check each consumer.
- **Not every context loads `application-bytechef.yml`.** It is pulled in via `spring.config.import` from `server-app`'s `application.yml:152`. Integration tests using `config/application-testint.yml`, the EE microservices (config-server), and `runtime-job-app` each have their own config root. Enumerate them before removing a default, or the default disappears for that context.
- **Test coverage is the real gate here.** `./gradlew test` will not catch a missing runtime default. Boot the server app *and* at least one EE app, and run `./gradlew testIntegration`.

## Acceptance criteria

- [ ] No field in `ApplicationProperties.java` carries a constant initialiser (nested-holder `= new X()` allocations excepted).
- [ ] Every previously-defaulted property appears in `application-bytechef.yml` with the value the application actually shipped with.
- [ ] The three confirmed drifts are resolved with the chosen value recorded in the commit message.
- [ ] EE `config-server-app` and `runtime-job-app` YAMLs cover every property their apps rely on; the stale `bytechef.ai.openai.*` path is fixed or removed.
- [ ] A test guards against reintroducing Java-side defaults.
- [ ] `./gradlew check` and `./gradlew testIntegration` pass; `server-app` boots and an EE app boots.

## Suggested commits

Server-side convention, one concern per commit:

- ` Move AI property defaults to application-bytechef.yml`
- ` Move coordinator and worker property defaults to application-bytechef.yml`
- ` Move storage and messaging property defaults to application-bytechef.yml`
- ` Reconcile the message broker, file storage basedir and discovery service defaults`
- ` Align the EE config server and runtime job app property defaults`
- ` Add a test guarding against Java-side property defaults`