imagemagick.org: libtool .la files carry +brewing build-prefix and stale dep versions

[tannevaled]

Symptom

Recipes that link against ImageMagick via autotools/libtool fail at link time with errors of the shape:

```
libtool: link: cannot find the library '/opt/littlecms.com/v2.18.0+brewing/lib/liblcms2.la'
```

The path is wrong on two axes:

1. The `+brewing` suffix is the sandboxed build prefix — it doesn't exist post-relocation.
2. The version `v2.18.0` doesn't match pantry's current `littlecms.com` (now `v2.19.1`).

Root cause

`projects/imagemagick.org/package.yml` ships `libMagickCore-7.la`, `libMagickWand-7.la`, `libMagickPP-7.la`, etc. directly out of the upstream install. Each `.la` file has a `dependency_libs=…` line that records the absolute path of every transitive dep's `.la` at build time — including the build sandbox prefix (`+brewing`) AND the specific version of the dep that was current when IM was bottled.

`projects/x.org/xdmcp/package.yml` (and a few siblings) already handle this by post-processing `.la` files at install time. But imagemagick doesn't.

Surfaced by

#13111 `new(autotrace)` debugging. Worked around in autotrace by renaming `libMagick*.la` → `.la.disabled` before `make install` so libtool falls back to plain `pkg-config --libs MagickCore-7` (`-L -lMagickCore-7.Q16HDRI`). That's the right pattern long-term — `.la` files are obsolete in 2026 — but doing it ad-hoc in every IM-consuming recipe is the wrong layer.

Suggested fix

In `projects/imagemagick.org/package.yml`, add a post-install step:

```yaml

.la files reference the build prefix (+brewing) and pinned dep versions.

Both rot at runtime: relocation strips +brewing, deps move forward

(lcms2 v2.18 → v2.19). Modern pkg-config provides the same info from

MagickCore-7.pc, so dropping the .la is cleaner than sed-rewriting.

• find {{prefix}}/lib -name 'libMagick*.la' -delete
  ```

(Or the sed-rewrite-`+brewing` pattern from `x.org/xdmcp` if there are consumers who NEED `.la` files. I don't know of any current consumer that does.)

Related

• x.org: x11.pc is empty #7443 (x.org: x11.pc is empty) had a related-but-inverted version of this problem (sed-pass on `.la` files corrupted neighbouring `.pc` files on macOS BSD sed). Fixed by `find . -name '*.la' -delete` in commit cd4bd81. Same fix should apply here.