SOURCE_DATE_EPOCH=0 (1970-01-01) rejected by timestamp range validation since 3.4.2

## Problem

`maven-jar-plugin` 3.4.2 (via `maven-archiver`) enforces a valid timestamp range of `1980-01-01T00:00:02Z` to `2099-12-31T23:59:59Z` on `project.build.outputTimestamp`. When `SOURCE_DATE_EPOCH=0` (Unix epoch, 1970) is set — a common reproducible-build convention used by Debian and many Apache projects — the build fails with:

```
Error assembling JAR: '1970-01-01T00:00:00Z' is not within the valid range 1980-01-01T00:00:02Z to 2099-12-31T23:59:59Z
```

This was working fine with `maven-jar-plugin` 3.3.1. The range constraint comes from the ZIP/JAR format requiring timestamps ≥ 1980, which is correct for the JAR's internal entry timestamps — but the user-visible error message is confusing and there is no automatic clamping to `DATE_MIN`.

## Steps to reproduce

1. Set `SOURCE_DATE_EPOCH=0` (or `project.build.outputTimestamp=1970-01-01T00:00:00Z`) in your build environment.
2. Build a project using `maven-jar-plugin` 3.4.2.
3. Build fails with the above error.

## Expected behavior

Either:
- **Clamp automatically**: If `project.build.outputTimestamp` is before `DATE_MIN` (1980-01-01T00:00:02Z), use `DATE_MIN` instead and emit a warning. This is what many other tools do.
- **Or reject with a clear message**: Document the minimum accepted value and link to the reproducible-builds guidance that `SOURCE_DATE_EPOCH` must be ≥ `315532802` (1980-01-01T00:00:02Z) when used with JDK jar tooling.

## Affected versions

- 3.4.2 (regression vs 3.3.1)

## Context

Found while running Maven 4 compatibility tests across Apache projects. Affected projects: `sling-org-apache-sling-karaf-integration-tests`, `sling-org-apache-sling-karaf-launchpad-oak-tar-integration-tests`.

The [Reproducible Builds mailing list](https://lists.reproducible-builds.org/pipermail/rb-general/2026-February/004045.html) documents that `SOURCE_DATE_EPOCH=0` is commonly used and that the JDK `jar` tool imposes the 1980 floor — a clear error message or automatic clamping would help users.

Reproduce the failure with SOURCE_DATE_EPOCH=0 and project.build.outputTimestamp using maven-jar-plugin 3.4.2, then compare behavior with 3.3.1 and inspect the timestamp validation in maven-archiver. Determine whether the project will clamp values or improve the rejection guidance; done means the chosen behavior is covered by a regression test and clearly documented.

Written by the indexing model from the issue text.