Document DaprApp.++ semantics (no dedup; collisions surface at validation)

[sideeffffect]

Severity: low · Category: DX / docs

Evidence

• src/DaprApp.scala:40-48 — ++ is field-wise List ++ List with no dedup/normalisation.
• validateOrThrow (:66) is invoked only by Dapr.serve (src/Dapr.scala:184), not by ++.

Problem
Composing two modules that both register e.g. InvocationMethodName("get") produces a DaprApp that looks fine until serve throws DaprAppValidationException. The ++ doc doesn't warn that collisions surface later.

Suggested fix
Add to ++'s scaladoc: "Concatenates field-wise preserving order; does not deduplicate — name/route collisions between the two apps are reported by validationErrors/validateOrThrow (and by serve at startup)." Optionally expose a documented DaprApp.empty identity for folding module lists.

[sideeffffect]

Confirmed: src/DaprApp.scala:40-48 ++ is field-wise List ++ List with no dedup, and validateOrThrow() (:66) runs only via Dapr.serve, so a collision introduced by ++ stays latent until startup. The class-level scaladoc (:29) only says "can be combined with ++."

Suggested scaladoc on ++ (currently undocumented):

  /** Concatenate two apps field-wise, preserving order; does not deduplicate.
    *
    * Name/route collisions between the two apps (e.g. both register
    * `InvocationMethodName("get")`) are NOT detected here — they surface later via
    * [[validationErrors]] / [[validateOrThrow]], and at startup in [[Dapr.serve]],
    * which throws `DaprAppValidationException`. Call `.validateOrThrow()` after
    * folding modules to fail fast.
    */
  def ++(other: DaprApp): DaprApp = ...

The optional DaprApp.empty is worth adding — the companion at :71-72 is currently empty (object DaprApp), so folding a module list needs an explicit DaprApp() seed. A documented identity reads better and pairs with ++:

@scala.caps.assumeSafe
object DaprApp:
  /** Identity for `++`: an app with no handlers. `modules.foldLeft(DaprApp.empty)(_ ++ _)`. */
  val empty: DaprApp = DaprApp()

(++ is already associative with DaprApp() as identity, so this just names the existing monoid.)