Add slides on the cost of adding dependencies

Module 04 introduces dependencies and how to manage them with uv, but doesn't discuss the harder question: **should you add this dependency at all?**

This is especially relevant for scientific/engineering packages where a single poorly chosen dependency can make installation painful for end users (think compiled C extensions that won't build on a colleague's Windows laptop).

## The two camps

In practice, teams tend to fall into two extremes:

1. **"Not invented here"** — rebuild everything from scratch, avoiding external code even when well-tested libraries exist. This leads to buggy reimplementations and wasted effort.
2. **"`pip install` whatever"** — especially common with junior developers, grabbing packages without considering licensing, long-term maintenance, or what you're pulling into your dependency tree.

Neither extreme is right. The goal is to make **deliberate, informed choices** about each dependency.

## Suggested slide content

A new slide section in `04_dependencies_ci.qmd`, after the current "Dependencies" intro and before "Dependency resolution". Suggested bullets:

- **Every dependency is a trust decision** — you're shipping someone else's code to your users. In 2016, an npm developer unpublished a tiny 11-line package called "left-pad" and broke thousands of projects worldwide, including React and Babel. Your water model shouldn't stop working because a string-padding library disappeared.

- **Transitive dependencies add up fast** — adding one package can silently pull in dozens more. Each one is a potential point of failure — version conflicts, broken releases, or abandoned maintenance. Run `uv pip tree` to see what you're actually shipping.

- **Supply chain attacks are real** — malicious code has been injected into popular packages (npm's event-stream, Python's ultralytics on PyPI). The more dependencies you have, the larger your attack surface. For packages used in infrastructure or safety-critical modelling, this matters.

- **Check the license** — not all open-source licenses are equal. GPL dependencies can force your entire package to be GPL. Some licenses restrict commercial use. Always check before adding — your legal team will care even if you don't.

- **Consider the maintenance horizon** — will this dependency still be maintained in 3 years when your model is in production? Check: How many maintainers? How recent are the releases? Is there a bus factor problem? For scientific packages, also check: does it require compiled extensions that complicate installation?

- **When NOT to add a dependency** — if you only need one function from a large library, consider copying the logic (with attribution). If the functionality is 10-20 lines of straightforward code, just write it yourself. Your future self debugging an install issue on a server will thank you.

- **When TO add a dependency** — don't reinvent NumPy or pandas. Well-established, well-maintained packages with large communities (numpy, scipy, matplotlib) are safer bets. The key question: does this dependency solve a genuinely hard problem that would be error-prone to implement yourself?

## Placement

Between the current opening slide ("Dependencies are other pieces of software...") and "Dependency resolution" in `04_dependencies_ci.qmd`. Could be 1-2 slides titled something like "Should you add this dependency?".

## Group work tie-in

Q3 in `group_work/04_module.md` already asks about conflicting dependencies. Could add a follow-up: "Have you ever regretted adding a dependency? Or avoided one and regretted reimplementing it yourself?"