pampa - make quarto-system-runtime optional via filters feature

[rundel]

Context

I've been playing around with building an R wrapper around q2/pampa and I've run into an issue building it on linux. See https://github.com/rundel/q2r if interested.

Issue

Library consumers of pampa that use only the parser and writer cannot build on Linux. pampa::unified_filter is unconditionally exposed from lib.rs and imports quarto_system_runtime::SystemRuntime, which transitively pulls deno_core and the v8 prebuilt static archive. default-features = false on pampa does not drop this — quarto-system-runtime is a non-optional workspace dep.

The Linux x86_64 v8 static was compiled with the local-exec TLS model, so linking it into a consumer's cdylib fails. macOS escapes this because Mach-O TLS goes through a runtime descriptor lookup that's identical in executables and dylibs.

$ cargo tree --no-default-features -i deno_core
deno_core v0.376.0
└── quarto-system-runtime v0.1.0
    └── pampa v0.0.0
        └── <consumer-cdylib>

$ cargo build --lib   # consumer crate-type = ["cdylib", "staticlib"]
/usr/bin/ld: target/debug/libconsumer.a(api.o): relocation R_X86_64_TPOFF32 against
  hidden symbol `_ZN2v88internal18g_current_isolate_E' can not be used when making
  a shared object
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

Sketch of fix

Feature-gate quarto-system-runtime in crates/pampa/Cargo.toml (mark optional = true), add a filters feature that pulls it in, gate pub mod unified_filter; and pub mod citeproc_filter; in crates/pampa/src/lib.rs behind that feature, and make the existing json-filter and lua-filter features depend on filters. Default features stay as today, so binary and existing library consumers see no change. Parser-only consumers can then opt out with default-features = false.

[cscheid]

Without any further inspection than a cursory read of the report, this is strange to me, because we build on Linux in CI all the time...

[rundel]

The build issue is not with pampa but with the q2r R package - when I try linking against the rust crates it creates the linking error with deno -> v8.

[cscheid]

Ah! Gotcha, I understand it now. I think this makes sense for us to do right now, but I can't really guarantee that we won't violate this in the future!

I would like to figure out a way to be able to make that promise such that we can keep the commitment, but our focus isn't currently in making these libraries easy to link against for developers.

[rundel]

Totally fine by me - I dont need any guarantees at all, this is all a toy for me to play with for the foreseeable future.

Definitely something nice to have eventually once everything is stable and working.