requires.input ranges are rejected by package-spec, but elastic-package build surfaces a confusing EPR 400

## Summary

`requires.input[].version` for input package dependencies must be an exact semantic version, not a version range. This is already enforced by `package-spec` semantic validation, and `elastic-package lint` reports that validation error correctly.

The confusing failure happens when running `elastic-package build` directly. The build flow downloads and bundles required input packages before built-package validation runs, so a range such as `^1.0.0` is passed to the EPR artifact endpoint before package-spec validation has a chance to surface the clearer error.

The remaining gaps are:

1. `package-spec` schema/type description still says exact input versions are only recommended, which conflicts with the existing semantic validator.
2. `elastic-package build` should fail fast before calling EPR when `requires.input[].version` is not an exact semver.
3. `elastic-package` registry download errors could include more useful context when EPR returns a non-200 response.

## Current Behavior

Given:

```yaml
requires:
input:
- package: filelog_otel
version: "^1.0.0"
```

`package-spec` semantic validation rejects it with a clear error:

```text
field requires.input.0.version: version "^1.0.0" for package "filelog_otel" must be a valid semantic version, constraints are not allowed
```

`elastic-package lint` shows this validation error. `elastic-package check` also shows it because `check` runs `lint` before `build`.

But `elastic-package build` can fail earlier while bundling required input packages, with an error like:

```text
building package failed: bundling input package templates failed: failed to download input package "filelog_otel": downloading package filelog_otel-^1.0.0: unexpected status code 400
```

That error does not tell the user that the manifest dependency version must be pinned.

## Expected Behavior

`elastic-package build` should validate `requires.input[].version` before calling EPR and fail with a clear, actionable error such as:

```text
requires.input version for package "filelog_otel" must be an exact semantic version, constraints are not allowed: "^1.0.0"
```

`package-spec` should also update the `requires.input` documentation/schema description so it matches the existing semantic rule.

## Where To Act

### package-spec

Update `spec/integration/manifest.spec.yml` around the shared `package_dependency` definition.

Current text says:

```text
For input packages, it is recommended to use specific versions...
```

This should say input packages must use exact semantic versions. Ideally split the shared dependency definition into separate input/content dependency definitions so examples and descriptions are not ambiguous:

- `requires.input[]`: exact semver only.
- `requires.content[]`: constraints allowed.

The semantic validator already exists in:

```text
code/go/internal/validator/semantic/validate_package_references.go
```

### elastic-package

Add fast validation before `RequiredInputsResolver` calls `DownloadPackage`, likely in:

```text
internal/requiredinputs/requiredinputs.go
```

Specifically before:

```go
r.eprClient.DownloadPackage(inputDependency.Package, inputDependency.Version, tmpDir)
```

Also consider improving `internal/registry/client.go` to include the response body for non-200 responses, since it already reads it but currently drops it from the error.

## Notes From Local Verification

- `elastic-package` currently depends on `github.com/elastic/package-spec/v3 v3.6.5`, which includes the semantic validation for exact input package versions.
- `elastic-package lint` runs package-spec source validation and reports this correctly.
- `elastic-package check` runs `lint` before `build`, so it also reports the validation before reaching the build download path.
- The problematic path is direct `elastic-package build`, where required input package bundling happens before built-package validation.