Invalid DROP_DEAD_FILE paths silently fall back to embedded lists

[welttowelt]

Problem:
Custom drop-list overrides silently fall back to the embedded lists when the path is missing or unreadable. This affects both DROP_DEAD_FILE and DROP_DEAD_SECOND_FILE in src/point_add/mod.rs on promoted commit da51a48.

Evidence:
On a clean worktree at origin/main / da51a48, after building the benchmark binaries:

env DROP_DEAD_FILE=/tmp/definitely-missing-drop-list.idx ./target/release/build_circuit

The build succeeds and applies the embedded first drop list:

DROP_DEAD_ROBUST: removed 13880 ops (10220088 -> 10206208)
DROP_DEAD_ROBUST_SECOND: removed 2638 ops (10206208 -> 10203570)

Likewise:

env DROP_DEAD_SECOND_FILE=/tmp/definitely-missing-second-drop-list.idx ./target/release/build_circuit

also succeeds and applies the embedded second list.

The code path is:

std::env::var("DROP_DEAD_FILE")
    .ok()
    .and_then(|path| std::fs::read_to_string(path).ok())

and the same pattern is used for DROP_DEAD_SECOND_FILE, so both read errors are discarded.

Effect:
A typo or stale path in a local tuning run produces a valid-looking op stream with the baked drop list instead of the requested candidate list. That can waste nonce hunts or make two runs appear comparable when they are not using the same drop indices.

Smallest useful fix:
If the override env var is present, read that exact file and return/panic on any error. Fall back to the embedded include_str! only when the env var is absent.

Gate:
DROP_DEAD_FILE=/missing ./target/release/build_circuit and DROP_DEAD_SECOND_FILE=/missing ./target/release/build_circuit should fail loudly before emitting ops.bin.