fix(build): tolerate unresolvable cargo metadata in filter discovery

[Ladas]

Problem

server/build.rs panics when cargo metadata cannot resolve praxis-ai-proxy's
manifest on its own:

panicked at server/build.rs:50:
failed to run cargo metadata: ... failed to get `praxis-ai-apis` as a
dependency of package `praxis-ai-proxy v0.3.0 (/vendor/praxis-ai-proxy)`

This happens whenever the manifest is read away from its workspace. Two real cases:

• cargo publish verification.
• A vendored build: cargo vendor flattens the tree, so the manifest's
  path = "../apis" no longer points anywhere. This blocks hermetic container
  builds, where dependencies are prefetched and the build itself runs with no
  network.

Fix

Praxis core's equivalent script, crates/server/build.rs, already handles this:
load_metadata returns Option<Metadata> and main falls back to an empty
registration. Its doc comment names the same cause — "Returns None when metadata
resolution fails (e.g. during cargo publish verification where path dependencies
are not available)."

This restores that behaviour, which was lost when the discovery logic moved into
praxis-ai-build-support. One addition over core: the fallback emits a
cargo::warning, so a downstream crate that expected its filters to be discovered
can see why they were not.

Why this is safe

build_full_registry registers Praxis AI's own filters explicitly:

let mut registry = praxis_filter::FilterRegistry::with_builtins();
praxis_ai_filters::register_ai_filters(&mut registry, Some(subrequest_client));
register_llmd_ext_proc(&mut registry);
register_external_filters(&mut registry);   // generated by build.rs

The generated function only ever covers third-party crates carrying
[package.metadata.praxis-filters]. A server built in a vendored context keeps its
full built-in pipeline; only third-party discovery is skipped, and it now says so.

Verification

• Vendored workspace built with --network none: before, aborted in this script;
  after, Finished release profile in 2m 10s and a working binary.
• cargo +nightly fmt --check, cargo check -p praxis-ai-proxy (which runs the
  script), cargo clippy -p praxis-ai-proxy --all-targets -- -D warnings: clean.
• cargo test -p praxis-ai-build-support: 10 passed. The fallback reuses
  generate_registration_code(&[]), already covered by
  generate_registration_code_emits_calls_and_empty_case_suppression.

No new tests: the change is in the build-script orchestrator, which by the file's own
note cannot carry unit tests; the logic it calls lives in build_support and is
unchanged.

Context

Found while making the experimental gateway image buildable by Konflux for an Open
Data Hub developer preview, where builds are hermetic. Opened as a draft for
maintainer review of the approach.

[praxis-bot]

praxis-bot review: fix(build): tolerate unresolvable cargo metadata in filter discovery

Clean, well-motivated change that restores the graceful fallback Praxis core already has. The approach is correct: load_metadata and active_features return Option, main writes an empty registration on the fallback path, and emit_static_rerun_directives ensures Cargo will re-run discovery when the workspace is repaired. The added cargo::warning is a good improvement over core's silent .ok().

Findings

#	Severity	File	Description
1	Medium	server/build.rs	Mixed Cargo directive syntax

---

Details below.