fix: write wasm build output to the reported artifact path

[paoloanzn]

Summary

• fix build wasm so the compiler writes to the same artifact path the CLI reports in JSON output
• fail the build if compilation returns successfully but the reported Wasm artifact is still missing
• add regression coverage for the relative --path services/orchestrator case that previously produced a false-success build

Problem

A user reported that this sequence could return success even though dist/app.wasm did not exist afterward:

rm services/orchestrator/dist/app.wasm
flare-edge-cli build --path services/orchestrator --json

The CLI reported:

• artifact: services/orchestrator/dist/app.wasm
• files: [services/orchestrator/dist/app.wasm, ...]

But the actual file was missing at that path.

Root Cause

The build service constructed the default artifact path by prefixing it with options.Path, and then invoked go build with Dir=options.Path.

That meant the compiler received an output path like:

services/orchestrator/dist/app.wasm

while already running inside services/orchestrator, so the effective compiler output path became a nested path like:

services/orchestrator/services/orchestrator/dist/app.wasm

The CLI then returned success and reported the non-nested path, which could leave users with a missing or stale artifact at the location they were told was built.

Fix

This PR:

• resolves the compiler output path to an absolute path before invoking go build or tinygo
• keeps the reported artifact path stable in the CLI result
• verifies after compilation that the reported artifact actually exists
• returns an error if the compiler reported success but the artifact is still missing

Testing

• go test ./internal/service/build
• go test ./...

Also verified with a real end-to-end build using a disposable nested project path matching the failure mode:

• scaffolded a real project under services/orchestrator
• ran flare-edge-cli build --path services/orchestrator --json from the parent directory
• confirmed services/orchestrator/dist/app.wasm exists and is a real WebAssembly binary
• confirmed the old erroneous nested output path was not created

User Impact

After this change, the reported artifact path and the actual compiler output path stay aligned. Builds that previously produced a silent false success should now either:

• write the Wasm binary to the expected dist/app.wasm path, or
• fail explicitly if that artifact is missing.