Replace LLVM backend panics with a typed code generation error channel

## Problem

The LLVM backend currently uses many `panic!`, `unwrap`, and `expect` calls for unsupported types, missing semantic facts, IR builder failures, target-machine failures, object emission, and external tool execution. The driver catches panics as a last resort, but users receive an internal-error style diagnostic and embedders cannot recover cleanly.

## Scope

- Define a typed backend error carrying phase, operation, optional source identity/span, and underlying LLVM/tool message.
- Make top-level IR/object/assembly emission APIs return `Result`.
- Convert expected user-triggerable failures first: invalid lowering inputs, LLVM builder errors, pass failures, target machine creation, file emission, and linker/tool launch.
- Reserve panic for documented impossible invariants.
- Translate backend errors once in the CLI to human and JSON diagnostics.
- Avoid string-matching panic messages in `src/runner.rs`.

## Completion criteria

- [ ] Public LLVM codegen entry points return `Result`.
- [ ] Representative invalid programs and missing-tool cases do not unwind.
- [ ] Human and JSON diagnostics include the backend phase.
- [ ] No partial output artifact is reported as successful.
- [ ] Tests distinguish a user/codegen error from an internal invariant violation.

Start by tracing the LLVM codegen entry points and the panic handling in src/runner.rs. Identify the emission, lowering, tool-launch, and diagnostic paths named in the issue before changing their interfaces. Done means public codegen returns Result, representative invalid and missing-tool cases do not unwind, diagnostics include the backend phase, and tests distinguish user errors from invariant violations.

Written by the indexing model from the issue text.