fix(publish): give publisher failures their own codes and keep cargo's full error

[BryanFRD]

Closes #1272

Codes. Every publisher error carried CONFIG_INVALID_PATH (E1018), whether the setup was wrong or the registry refused the upload, and E1018 had no entry in the error reference. Publishers now use two codes of their own, both documented in EN and FR under a new "Publisher Errors" section:

• E6101 PUBLISHER_MISCONFIGURED: undeclared registry, unset tokenEnv, missing build context, chart or asset file, unparsable Chart.yaml name, trustedPublishing outside GitHub Actions or without an https registry.
• E6102 PUBLISH_FAILED: the tool or endpoint ran and failed (cargo publish, npm publish, python -m build, twine upload, docker buildx, cosign sign, helm package/push, gh release upload, the PyPI OIDC exchange, webhooks).

E1018 stays for what it was named for, an invalid versioned-file path in src/formats.

Cargo output. first_meaningful_line kept only the last error: line and skipped any line starting with an ANSI escape. With colours on, cargo's error: line starts with one, so the message fell back to the last line of the cause chain (required by package ...), hiding the actual reason. The publisher now strips ANSI sequences and reports the last error: block with the Caused by lines that follow it.

This changes the code users see on a publish failure (E1018 becomes E6101 or E6102), which is the point: the old one was wrong and pointed at nothing.

[ferrfleet]

The code split looks right: setup and env problems map to E6101, tool and HTTP failures to E6102, and the webhook test now expects the new code. The only other E1018 assertion was the webhook one, and the new constants are pub in an ungated pub mod, so builds without the cli feature won't warn about dead code.

Nit: failure_report now puts newlines inside the error message. error_report_lines (src/error_report.rs) relies on each cause being one physical line. So the Caused by: block prints flush-left under error[E6102]: ..., without the two-space indent the other causes get, and the same happens in the [cargo] ERROR {e:#} line in publishers/mod.rs. It's readable, but splitting multi-line causes in error_report_lines and indenting each line would keep the report tidy.

Nit: E6102 in both language versions of the docs says the message carries "the lines that explain its cause" for every tool. Only cargo does that so far. npm and pypi still use first_meaningful_line, which keeps a single line. Either say it's cargo-only or move those two publishers over to failure_report as well.