fix: update config file handling in application initialization

[dmisic-godaddy]

The bug was: passing [--environment prod] to [init] command triggered [getConfigFile()] which threw if no godaddy.toml existed — even though you'd already supplied all the flag values. Fix handles that.

Without [--environment], the code now skips the config file entirely and falls through to [resolveEnvironmentEffect(undefined)], which reads ~/.gdenv, not godaddy.toml. That's separate and expected.

Additional improvement:
Swapped [getConfigFile] import for [getConfigFileEffect] since [appInit] is inside [Effect.gen], it should use [getConfigFileEffect].

[wcole1-godaddy]

A bit more context on why I think the current fix is too broad:

The issue here is not just "missing config file". It is really that application init is mixing together a few different concepts of environment/config targeting.

Current behavior is roughly:

• The user-facing CLI environment is ote|prod via godaddy env ... and the global --env flag.
• Lower envs (dev|test) are not first-class CLI envs, but we do support targeting them through env var overrides for the API base URL / client ID.
• Config file selection also tries to infer dev|test from those overrides.
• application init adds its own --environment flag on top of that.

Given that, I think the intended behavior should be:

1. Resolve the effective target once, using the same precedence rules the rest of the CLI uses.
2. Use that resolved target to decide which config profile/file to read.
3. If that config file does not exist yet, application init should still be allowed to proceed when all required flags are provided.
4. If the config file exists but is malformed / unreadable / schema-invalid, we should still fail and surface that problem.

The current patch fixes (3), but it also changes (4): on the env-only path it catches every ConfigurationError from getConfigFileEffect(...) and treats it as "no config". That means we now hide parse/read failures, not just missing-file cases. We also skip Ark/schema validation results unless --config was explicitly passed.

A few concrete implications:

• a broken godaddy.dev.toml or fallback godaddy.toml is treated as absent
• the user can get a misleading later error like "Application name is required" instead of the real config problem
• if init succeeds, it can overwrite the bad config with freshly generated content, which makes the original problem harder to diagnose

Stepping back, I think the bigger design fix is:

• application init should resolve the effective target env first
• it should automatically try the matching config profile for that target
• it should only tolerate the specific "config not found" case
• we should probably remove the command-local --environment flag entirely, because it is redundant with the global env selection and gets especially confusing when env vars are already forcing the CLI to a lower env

If we do keep a command-local env flag, I think it should only accept the public envs (ote|prod) and should not silently pretend it matters when the lower-env overrides are already in effect.

[dmisic-godaddy]

Thanks for the detailed review — you're right, the catch-all approach was too broad.

The core problem with the previous fix was that it caught every [ConfigurationError] from [getConfigFileEffect] and treated it as "file not found". That silently swallowed malformed TOML, unreadable files, and schema validation failures — exactly what you called out.

Here's what we changed:

Resolve env first. init now calls [resolveEnvironmentEffect] upfront, using the same precedence rules as the rest of the CLI (env var overrides → ~/.gdenv → default [ote]. The raw [--environment] string is no longer passed directly into [getConfigFileEffect].

Check existence before reading. We use [fileExists] to determine whether the target config file is present. If it's absent and no explicit [--config] was passed, we skip cleanly. If it's absent and [--config] was explicitly provided, we fail hard.

Fail hard on everything else. If the file exists, we read it and surface any error — bad TOML, unreadable, schema-invalid — without swallowing it. The [ArkErrors] path is now always checked, not just when [--config] was passed.

On the broader design point about removing [--environment] from init: agreed it's confusing when lower-env overrides are already active, but treating that as a follow-up for now since it's a breaking change and the current fix already narrows the scope correctly.