[BUG] Build panics when output permissions cannot be changed

> *This was generated by AI during triage.*

**Describe the bug**

Amber panics after it writes build output when the output target does not permit `chmod`. The panic comes from `file.set_permissions(perm).unwrap()` in `src/main.rs`.

Version: `amber fd743bd` (`fd743bd829af9e24705e1b855448757684112b95`) on Linux.

**To Reproduce**

```bash
cargo run --quiet -- build src/tests/validity/variable_simple.ab /dev/null --no-proc '*'
```

Actual result:

```text
thread 'main' panicked at src/main.rs:215:32:
called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }
```

**Expected behavior**

Amber should report a normal CLI error and exit with a non-zero status. It should not expose a Rust panic.

**Additional context**

`set_file_permission()` also unwraps `fs::metadata(path)`. Both filesystem errors can panic. Returning `io::Result` from permission and output helpers would let the CLI report these errors. Using `file.metadata()` would also avoid reading metadata through the path again.

Start in src/main.rs at set_file_permission() and the file.set_permissions(perm).unwrap() call around line 215, then trace the permission and output helpers mentioned in the issue. Run the provided cargo build command against /dev/null and verify that filesystem failures produce a normal CLI error with a non-zero exit status instead of a Rust panic.

Rédigé par le modèle d'indexation à partir du texte de l'issue.