Minor optype tidiness: unused Duration import; DaprPort admits 0

[sideeffffect]

Severity: low · Category: tidiness

Evidence

• src/optypes/DaprDuration.scala:3 — imports {FiniteDuration, Duration} but only FiniteDuration is referenced (dead import).
• src/optypes/DaprPort.scala:13 — accepts 0 (n >= 0 && n <= 65535); the doc says "0–65535" so code/doc agree, but 0 is not a connectable sidecar port.

Suggested fix
Drop the unused Duration import. Optionally tighten DaprPort to 1–65535 if an ephemeral port is never bound via this type. (CloudEventSpecVersion's non-empty-only validation is correct for a forward-compatible inbound field — leave it.)

[sideeffffect]

Both verified in the worktree.

Unused import. src/optypes/DaprDuration.scala:3 is import scala.concurrent.duration.{FiniteDuration, Duration}, but Duration is never referenced in the file (Duration.Zero lives in DaprConfig.scala, not here). Drop it:

import scala.concurrent.duration.FiniteDuration

DaprPort admitting 0. src/optypes/DaprPort.scala:13 enforces n >= 0 && n <= 65535, and the Scaladoc says "0-65535", so code and doc currently agree. Tightening to 1-65535 is reasonable only if no caller relies on 0 to mean "OS picks an ephemeral port". The two uses I see are SidecarConfigs endpoints (3500/50001) and AppServerConfig.port (default 8080) in DaprConfig.scala — all concrete, connectable ports, none ephemeral. So tightening is safe:

require(n >= 1 && n <= 65535, s"Port must be in range 1-65535, got $n")

Update the doc comment to match ("1-65535"). If you would rather keep 0 as a future ephemeral-bind affordance, leave it and the import fix alone stands.