[eas-build-job] Accept legacy command/path custom function shape in function.yml

[sswrk]

Why

First step toward grandfathering the older custom build functions into .eas/functions.

EAS Workflows can call reusable local functions defined in .eas/functions/<name>/function.yml, but until now such a file could only describe a composite function (a named group of steps). The older custom build functions from .eas/build configs (docs) are defined differently: a single shell command or a path to a prebuilt JS module. The body of such a function should work as a function.yml verbatim, so that moving one into .eas/functions is a copy-paste. Suggested in the review of the composite functions stack (#3928).

How

Widens the function.yml contract in @expo/eas-build-job, the single source of truth for its shape. A file now declares either runs.steps (a composite function) or command/path (a single-step function); the two shapes are mutually exclusive and mixing them produces a clear error.

• Adds LegacyFunctionConfigZ / LegacyFunctionConfig for the single-step shape: name, description, inputs (same shape as composite inputs, so the legacy YAML copies over verbatim), array-form outputs, command, path, shell, supported_platforms.
• Adds LocalFunctionConfigZ, the union both loaders will parse with. It sniffs the shape and delegates to one branch rather than unioning two strict objects, which keeps errors precise: a bare union reports every branch's failures for a single typo. Sub-schema issues are re-emitted with their paths intact, so the existing z.prettifyError formatting keeps working.
• Adds the isLegacyFunctionConfig guard, plus command/path/shell/supported_platforms as z.never().optional() on the composite schema (the StepZ narrowing pattern) so the union discriminates in TypeScript.

No runtime behavior changes yet. The CompositeFunctionCatalog widening lands in the next PR, together with the @expo/steps code that handles both shapes, so that every commit in the stack typechecks on its own.

Test Plan

cd packages/eas-build-job && yarn test src/__tests__/compositeFunction.test.ts

Unit tests cover both shapes, the conflict cases (runs + command, runs + path, both command and path, neither) with exact error messages, cross-shape outputs rejection, unknown supported_platforms values, non-mapping input, unknown keys, and that prettified errors still point at the offending field.

[linear-code]

ENG-25402

[sswrk]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• [eas-cli] Validate legacy command/path local functions referenced from workflows #4098
• [build-tools] Load legacy command/path local functions and resolve module paths #4097
• [steps] Expand legacy command/path local functions to a single build step #4096
• [eas-build-job] Accept legacy command/path custom function shape in function.yml #4095 👈 (View in Graphite)
• [eas-cli] Validate local composite functions referenced from workflow hooks #4064
• [build-tools] Load composite function catalogs for hook steps #4063
• [steps] Support local composite functions in hook steps #4062
• [steps] Unify the default gating of steps with no if: across steps, composite scopes, and hooks #4061
• [eas-cli] Validate local composite functions in workflow files #3931
• [build-tools] Load local composite function catalog at build runtime #3930
• [steps][4/4] Resolve composite function outputs #4015
• [steps][3/4] Interpolate composite function inputs #4014
• [steps][2/4] Expand composite function references into build steps #3929 : 1 other dependent PR (#4013 )
• [steps][1/4] Add isCompositeFunctionPath and reject local composite functions in custom builds #3956
• [eas-build-job] Add local composite function schema #3928
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

⏩ The changelog entry check has been skipped since the "no changelog" label is present.