removeFromOutdatedResources() fallback path never matches due to path mismatch

## Description

In `EarMojo.java:886-897`, the `removeFromOutdatedResources()` method has a fallback path that will never match:

```java
try {
relativeDestFile = getWorkDirectory().toPath().relativize(destination.normalize());
} catch (ProviderMismatchException e) {
relativeDestFile = destination.normalize(); // absolute path
}
if (outdatedResources.remove(relativeDestFile.toString())) { ... }
```

When a `ProviderMismatchException` occurs (e.g., zip filesystem path vs local filesystem path), the fallback stores an absolute path. However, `outdatedResources` contains only relative paths (from `initOutdatedResources()` at line 857). The `remove()` will never match, so cleanup silently fails for those paths.

## Expected behavior

Attempt to relativize differently, or at minimum log that cleanup could not be performed for that path.

Start in EarMojo.java:886-897 and inspect initOutdatedResources() around line 857 to compare the stored relative paths with the fallback path. Reproduce the ProviderMismatchException case involving zip and local filesystem paths. Done means cleanup can match the outdated resource, or clearly logs when cleanup cannot be performed.

Written by the indexing model from the issue text.