Fix failing CI: exception propagation across toolchains and rchk PROTECT stack depth

[Copilot]

The rchk, clang16, c23, and noremap CI jobs were failing from two unrelated C++ issues: R errors lost during exception rethrow on certain toolchains, and an over-deep PROTECT stack flagged by rchk.

Exception propagation (clang16, c23, noremap)

fmap/fmap2 error tests failed with c++ exception (unknown reason). The code rethrew the in-flight Rcpp::LongjumpException via std::rethrow_exception(std::current_exception()). Since current_exception() may return a copy and LongjumpException is not derived from std::exception, the rethrown object stopped matching Rcpp's catch(LongjumpException&) handler, fell through to catch(...), and discarded the original R condition.

• Replaced these rethrows with bare throw; (preserves the exact in-flight object) in src/map.cpp, src/mapreduce.cpp, src/load.cpp.

} catch (const Rcpp::LongjumpException& e) {
    // let R continue the longjmp with the original condition
    throw;            // was: std::rethrow_exception(std::current_exception());
}

rchk PROTECT stack depth

rchk reported "protect stack is too deep" in FARR_buffer_map/FARR_buffer_map2 (src/map.cpp) and locationList/schedule (src/core.cpp), caused by PROTECT inside loops with non-constant iteration counts (an n_protected counter incremented per iteration).

• Allocate buffer elements straight into the PROTECTed container via SET_VECTOR_ELT instead of protecting each one.
• In schedule, PROTECT per-partition temporaries locally and UNPROTECT them each iteration once stored — tmp is held by the PROTECTed sliceIdx2, idx2tmp by the Rcpp List idx2s (R-preserved after push_back) — bounding stack depth.
• locationList evaluates a promise under a single scoped PROTECT released after the coerced result is stored.

Notes for reviewers

• A review flagged a potential GC gap after UNPROTECT in schedule; this is a false positive — idx2s is an Rcpp List, not a std::vector<SEXP>, so it GC-protects its contents (verified under gctorture).