[BUG] The new try/except BuildError only wraps the ZIP build path (_build_function_on_container and _build_function_in_process). It is placed inside the if packagetype == ZIP: block, so several other BuildError sources remain unwrapped and will produce JSON error payloads with no resource field — which is the PR's headline improvement:

• _build_lambda_image (called for packagetype == IMAGE at line 741) raises DockerBuildFailed at lines 440, 443, 449, 493 and DockerfileOutSideOfContext at lines 496, 505.
• _build_layer (lines 541–678) calls _build_function_on_container / _build_function_in_process for layers with no surrounding try/except.
• build_single_layer_definition in samcli/lib/build/build_strategy.py:216 raises MissingBuildMethodException (a BuildError subclass).

For an Image function or a layer that fails to build, the JSON output will be:

{
 "status": "failure",
 "error": {
   "type": "DockerBuildFailed",
   "message": "..."
 }
}

...with no resource key, contradicting the PR description. Consider moving the assignment closer to where the resource is known — for example, attach resource_name at the strategy layer where function.full_path / layer.full_path is already available, so it covers Zip functions, Image functions, and Layers uniformly:

try:
   ...  # build_single_function_definition / build_single_layer_definition body
except BuildError as ex:
   if ex.resource_name is None:
       ex.resource_name = resource.full_path
   raise

Alternatively, duplicate the current try/except in _build_lambda_image and _build_layer.

[BUG] The new wrapper only catches BuildError, so the resource field is still missing from JSON error output for exceptions that are raised during a per-function build but are not BuildError subclasses. The outer except in build_context.py catches five additional types, three of which originate from a specific function build:

• UnsupportedRuntimeException — raised in ApplicationBuilder._build_function when a deprecated runtime is used (app_builder.py:752).
• BuildInsideContainerError — raised in _build_function_on_container on Docker image pull failures (app_builder.py:1072, 1097).
• UnsupportedBuilderLibraryVersionError — raised in _build_function_on_container when the container is missing the builder executable (app_builder.py:1049, 1105).

For any of these, the JSON payload emitted from build_context's error handler will not contain a resource field, which is precisely the PR's headline improvement ("the text error today does not identify which function failed"). Users on the container path or on a deprecated runtime will still see anonymous JSON failures.

Broaden the wrapper to tag any exception that surfaces from the per-definition build with the failing resource, for example:

def build_single_function_definition(self, build_definition: FunctionBuildDefinition) -> Dict[str, str]:
   try:
       return self._do_build_single_function_definition(build_definition)
   except (
       BuildError,
       UnsupportedRuntimeException,
       BuildInsideContainerError,
       UnsupportedBuilderLibraryVersionError,
   ) as ex:
       if getattr(ex, "resource_name", None) is None:
           ex.resource_name = build_definition.get_full_path()
       raise

Note that UnsupportedRuntimeException, BuildInsideContainerError, and UnsupportedBuilderLibraryVersionError do not currently define resource_name in their __init__, so either add the attribute to them (mirroring the change to BuildError) or rely on dynamic attribute assignment. The same broadening is needed for build_single_layer_definition.