fix: fixes excessive alias count error

[bbjay]

What is this PR about?

• Adds our own parse method with identical signature, which then forwards calls to yaml.parse with option {maxAliasCount: 10000} (overridable) applied -> fixes docker-compose.yml: Excessive alias count indicates a resource exhaustion attack #3924
• ensure our own parse method is used everywhere (also in tests)
• added test case for compose file with many (+200) aliases

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance. If you have not tested it yet, please do so before submitting. This helps avoid wasting maintainers' time reviewing code that has not been verified by you.

Issues related (if applicable)

closes #3924

Greptile Summary

This PR fixes the ReferenceError: Excessive alias count indicates a resource exhaustion attack error by introducing a thin wrapper around yaml.parse that raises maxAliasCount from the default 100 to 10,000 (overridable). All 34 changed files migrate their yaml imports to the new wrapper, and a regression test with 205 alias references is added to confirm the fix.

Key changes:

• packages/server/src/utils/yaml/index.ts: New wrapper that re-exports stringify and YAMLParseError directly from yaml while overriding maxAliasCount to 10,000 for parse
• All test files and server-side utilities consistently swapped from "yaml" for from "@dokploy/server/utils/yaml" or the relative ../yaml path — no direct yaml imports remain outside the wrapper itself
• A new test case validates parsing with 205 aliases without throwing

Issues found:

• The wrapper only implements one of the two yaml.parse overloads — the reviver-function variant (parse(src, (key, value) => ...)) is silently swallowed as an options object. Not a current bug, but the API is not fully equivalent to the original.

Confidence Score: 4/5

• This PR is safe to merge; the fix is correct and well-tested, with one minor signature gap in the yaml wrapper.
• The core change is a focused, low-risk fix — raising the YAML alias limit via a thin wrapper. All call sites have been migrated consistently, including tests. The only concern is the missing reviver-function overload in the wrapper, which is not used anywhere in the codebase today but makes the stated "identical signature" claim inaccurate and could become a silent bug if someone adds a reviver call in the future.
• packages/server/src/utils/yaml/index.ts — the parse wrapper is missing the reviver-function overload.

_{Last reviewed commit: 08a172c}

Greptile also left 1 inline comment on this PR.

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}

[greptile-apps]

Missing reviver overload

The PR description states this wrapper has an "identical signature", but the yaml library's parse function actually has a second overload:

// overload 1 (implemented)
parse(src: string, options?: ParseOptions & ...): any

// overload 2 (missing)
parse(src: string, reviver: (key: any, value: any) => any, options?: ParseOptions & ...): any

If a caller passes a reviver function as the second argument, it will silently be interpreted as the options parameter and spread into the options object — the reviver will never be called. No callers in the current codebase use the reviver variant, so this isn't an active bug, but the missing overload is a correctness gap. Consider adding the second signature to fully match the original API:

export const parse: typeof yaml.parse = (
  src: string,
  reviver?: ((key: any, value: any) => any) | (yaml.ParseOptions & ...),
  options?: yaml.ParseOptions & ...,
): any => {
  if (typeof reviver === "function") {
    return yaml.parse(src, reviver, { maxAliasCount: 10000, ...options });
  }
  return yaml.parse(src, { maxAliasCount: 10000, ...reviver });
};

[bbjay]

I could add that, but I really don't like the signature of that new function, i'ts almost unreadable. Given that we don't use the reviver option anywhere, I think it's better to keep it that way. One could always add a parseWithReviver() method to our utility.

IMHO this is a great example why function overloads are a bad language feature. Optional named parameters are the better alternative (well, not the way TS implemented it).