feat(harness): support sandbox-side artifact delivery without host byte buffering

### Problem

`ArtifactDeliveryTool.deliverArtifact` unconditionally calls `filesystem.downloadFiles(...)` before invoking `ArtifactDeliveryTarget`. `ArtifactDeliveryRequest` carries a `byte[]`, so the entire artifact must pass through the host JVM even when the sandbox could upload it directly to object storage or WebDAV.

For large reports, archives, and videos this adds host heap pressure and a sandbox-to-host transfer. A target cannot opt out because it is called only after the download. This follows up on the delivery tool introduced for #2663.

### Proposed change

Add an opt-in path-based delivery SPI that receives the active filesystem, per-call runtime context, and normalized source/destination metadata before any download. Applications can then implement sandbox-side uploads through their backend SDK or shell, without host byte materialization.

Keep existing byte-based target implementations and builder configuration compatible. Preserve input validation, destination conflict handling, and `force`. A direct-upload failure should be returned, not silently retried through a full in-memory download.

### Acceptance criteria

- Direct delivery never invokes `downloadFiles`, including failure/conflict paths.
- Normalized source path, active filesystem, runtime context, destination name, description, and `force` reach the target.
- Existing byte-based targets retain their behavior.
- Document application responsibility for backend path resolution, upload execution, source checks, and destination conflicts.