CLI silently ignores .fga.yaml config file when YAML parsing fails

Description

The OpenFGA CLI silently ignores the .fga.yaml configuration file when it contains invalid YAML syntax (such as tab characters), leading to confusing debugging sessions where the CLI appears to ignore the configuration without any error message.

Current Behavior

When a .fga.yaml file exists but contains invalid YAML (e.g., tab characters instead of spaces), the CLI:

• Does not throw any error or warning
• Silently falls back to other configuration sources (flags/environment variables)
• Gives no indication that the config file was found but failed to parse
• Proceeds as if the config file doesn't exist

Expected Behavior

When a .fga.yaml configuration file is found but fails to parse, the CLI should:

• Display a clear error message indicating the config file was found but couldn't be parsed
• Show the file path that was attempted
• Provide helpful information about the parsing error (e.g., "YAML does not support tab characters")
• Exit with a non-zero status code or at least warn the user

Steps to Reproduce

1. Create a .fga.yaml file with the following content (note: use a TAB character for indentation instead of spaces):

api-url: https://api.example.com
store-id: 12345678
<TAB>api-token: your-token-here

2. Try to run any CLI command that uses configuration:

fga store list

3. Observe that the CLI doesn't use the config file and doesn't report any error

Additional Context

According to YAML FAQ #2, tabs are not allowed in YAML, but this is easy to miss when creating config files manually or when copying examples.

Suggested Fix

Add validation for the config file loading process that:
If parsing fails, outputs a helpful error message.

Impact

Developer Experience (DX): This improvement would save developers debugging time and frustration. Good error messages are critical for CLI tools.

Start by reproducing the invalid .fga.yaml case with fga store list, then trace the CLI configuration-loading path. Confirm how parse failures are currently handled and define completion as a clear path-specific error or warning with a non-success outcome instead of silent fallback.