Assembling sometimes panics with "invalid source span: starting byte is out of bounds" (wrong procedure name, missing imports)

### Packages versions

miden-assembly: 0.20.6, 0.22.1

### Bug description

Assembling with `assembler.assemble_library` sometimes panics with `invalid source span: starting byte is out of bounds`. It's inconsistent, I've encountered it 3 times so far:
1. When calling nonexistent procedure from linked module eg `exec.output_note::create_note`
2. Missing import, actually I've misspelled module's name: `output_node` instead of `output_note`
3. To little locals declared in the decorator

### How can this be reproduced?

Assemble
```
use miden::protocol::output_note

@locals(1)
proc create_withdraw_return_note(tag: felt, note_type: felt, recipient: word, amount_0_out: felt, amount_1_out: felt)
# loc.0: note_id
# => [tag, aux, note_type, execution_hint, PAYBACK_NOTE_RECIPIENT]
exec.output_note::create_note
# => [note_id]
loc_store.0
# => []
###move assets to note

end
```

with
```
pub fn create_library(
assembler: Assembler,
library_path: &str,
source_code: &str,
) -> Result> {
println!("creating library: {:?}", library_path);
let source_manager = Arc::new(DefaultSourceManager::default());
// println!("parsing library: {:?}", library_path);
println!("parsing library: before parsing");
let module = Module::parser(ModuleKind::Library).parse_str(
AssemblyPath::new(library_path),
source_code,
source_manager.clone(),
)?;
// println!("Module: {:?}", module);
println!("parsing library: before assembling");
let library = assembler.clone().assemble_library([module])?;
Ok(library)
}
```

### Relevant log output

```shell
thread 'lp_withdraw_happy_path_test' (332150) panicked at /.../.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/miden-debug-types-0.20.6/src/source_file.rs:200:14:
invalid source span: starting byte is out of bounds
stack backtrace:
0: 0x101b2b814 - ::fmt::hfd528c9d14c1136f
1: 0x101b3a964 - core::fmt::write::h2ddadfca81aeb692
2: 0x101b043b4 - std::io::Write::write_fmt::hc70e63382e9f29d2
3: 0x101b0cca4 - std::sys::backtrace::BacktraceLock::print::hea663f6050de4073
4: 0x101b1025c - std::panicking::default_hook::{{closure}}::hbcaf474e707f3b7d
5: 0x101b10110 - std::panicking::default_hook::hff9145c2c6e89cdf
6: 0x101b10a54 - std::panicking::panic_with_hook::he6431e171a67d1a5
7: 0x101b1073c - std::panicking::panic_handler::{{closure}}::h42f8d27eb97efb5c
8: 0x101b0cdb0 - std::sys::backtrace::__rust_end_short_backtrace::h0de35f7407a5e0d8
9: 0x101afc490 - __rustc[eb8946e36839644a]::rust_begin_unwind
10: 0x101b74a68 - core::panicking::panic_fmt::h96de7a67cc512650
11: 0x101b74604 - core::option::expect_failed::ha7eb9005b8b6a5f0
12: 0x1019b9038 - ::column::h9b2e4ac4703ed88a
13: 0x1019c3fd4 - miden_miette::handlers::graphical::GraphicalReportHandler::render_context::hd576b2d35f7f9eb6
14: 0x1019c6ec4 - miden_miette::handlers::graphical::GraphicalReportHandler::render_snippets::h1f92ef4a85cab5b1
15: 0x1019bdad8 - ::debug::h00cbdd16dd1891ec
16: 0x101b3a964 - core::fmt::write::h2ddadfca81aeb692
17: 0x101b36838 - alloc::fmt::format::format_inner::h0dad41b42c4e8ea8
18: 0x101b4bfcc - anyhow::__private::format_err::h6f1e7e5c40df7aae
19: 0x101b4b6c0 - c_prod_pool::pool_ops::get_lp_local_library::{{closure}}::h20da46cb7a058082
20: 0x100eaf20c - c_prod_pool::pool_ops::get_lp_local_library::hfc2c936a57145a7c
21: 0x100da1f78 - unit::test_utils::setup_lp_local_test_environment::{{closure}}::h9143e6d188439a6a
22: 0x100dab46c - unit::lp_withdraw_happy_path_test::{{closure}}::h43435af987957ff3
23: 0x100e2cb28 - tokio::runtime::scheduler::current_thread::Context::enter::h9b75265dd47f20dd
24: 0x100e3cea0 - tokio::runtime::context::scoped::Scoped::set::ha7081f47cd471cf4
25: 0x100e2cecc - tokio::runtime::scheduler::current_thread::CoreGuard::block_on::h2083dd7c2307decc
26: 0x100e3d248 - tokio::runtime::context::runtime::enter_runtime::h468a539bff4783c5
27: 0x100e3d434 - tokio::runtime::runtime::Runtime::block_on::ha0db34a5f796b489
28: 0x100d7e35c - core::ops::function::FnOnce::call_once::hd83d9a67de3b4cfe
29: 0x100e7def0 - test::__rust_begin_short_backtrace::h93149138d9ae3a61
30: 0x100e8e4d0 - test::run_test::{{closure}}::h487317312ee09dd0
31: 0x100e6d108 - std::sys::backtrace::__rust_begin_short_backtrace::h9e2ac0c09322548d
32: 0x100e70070 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h23882ec12939e9e6
33: 0x101b0a310 - std::sys::thread::unix::Thread::new::thread_start::h96f5a914e64457ad
34: 0x19b2abc08 - __pthread_cond_wait
```

Edit: issue persists in v0.14 miden-assembly crate 0.22.1