Environment variables are replaced as text before the YAML is parsed, which can break the config

What happens

When we load an .afm.md file, the code first does a find-and-replace for ${env:...}
variables on the raw text, and then parses the YAML. Because the value is pasted in as
plain text before parsing, if the value has characters that mean something in YAML (like a
: or a new line), it can break parsing or change the config in ways the author didn't write.

Example

Say the file has:

model:
  name: gpt-4o
  authentication:
    type: bearer
    token: ${env:TOKEN}

If TOKEN is something like abc: def (a normal-looking secret), after substitution the
text becomes:

    token: abc: def

Now there are two colons on one line, so YAML fails with:

Invalid YAML in frontmatter: mapping values are not allowed here

Even though the secret itself is perfectly fine.

A worse case: if an env value contains a new line, it can add extra YAML keys that were never
in the file. For example a value like openai\n url: http://something ends up adding a
url: field under model, which wasn't written by the author.

Why this is a problem

• Real secrets/tokens can contain special characters, so loading can fail for no obvious reason.
• In setups where the env values are set somewhere else (CI, a deploy platform, etc.), a value
  could end up changing the config in unexpected ways.

Steps to reproduce

1. Set an env var with a colon in it, e.g. TOKEN="abc: def".
2. Use it in the frontmatter as token: ${env:TOKEN}.
3. Load the file → YAML parse error.

Possible fix (idea)

Parse the YAML first and then resolve the variables on the values, so the value is always
treated as plain text and not as part of the YAML structure.

Locate the loader for .afm.md files that substitutes ${env:...} before YAML parsing, then reproduce the issue with TOKEN="abc: def". Change the loading flow so environment values are resolved after parsing and remain plain text, and verify that colon and newline values no longer cause parse errors or add YAML keys.