feat(repo): schema encode slow metrics + entity state

[omegent-app]

Why

Prod Honeycomb (scanner APIs) shows event-loop delay max spikes of ~0.5–1.5s that line up with repository schema encode, not PDF work. The worst entity is BauhausOrder (max encode ~1.0s); MultiPickDeliveryNote / MakoOrder also have multi-hundred-ms tails. Existing metrics already label app.entity, but:

• histogram buckets stop at 1s and are coarse in the 100–1000ms band, so p99 of the heavy entities looks “fine” (~17ms) while MAX is ~1s
• there is no rate of slow encodes to alert on by entity

What

• Widen app.schema.{encode,decode}.duration histogram buckets through multi-second stalls
• Count app.schema.slow when duration ≥ 100ms, with app.entity + operation attributes
• Annotate spans: app.schema.slow, and on encode app.entity.state from the first item’s _tag (so we can see which Bauhaus order states burn CPU)
• Tests for slow flag + entity state annotation

Dig notes (BauhausOrder encode path)

Why a single-item save can still cost 0.5–1s:

1. Full aggregate re-encode on every Repository.saveAndPublish — one Order document embeds nested items[] (tagged line-item phases) + packages[] (tagged package/BB phases) + ReadonlyMap packs, addresses, etc. Cosmos body ~30KB avg / ~80KB max.
2. Schema shape is a deep TaggedUnion (OrderState × item/package unions) — encode walks the full tree even for tiny field changes.
3. Encode is sync on the Node event loop (no worker); app.schema.encode.duration_ms on the save span has no child spans for the CPU portion.
4. User fields use encodeKeys → id only; resolver is decode-path, not the encode stall.

After this lands + scanner bumps: alert on RATE(app.schema.slow) grouped by app.entity, and filter spans with app.schema.slow=true / app.entity.state.

How

timeSchema in packages/effect-app/src/Model/Repository/internal/internal.ts — histogram bounds, slow counter, span attrs; encode call sites pass state tag.

Remarks

• Alert suggestion once published: Honeycomb metrics SUM/RATE app.schema.slow where app.entity in (BauhausOrder, MakoOrder, MultiPickDeliveryNote) — not overall encode p99.
• Follow-up (scanner, not this PR): profile BauhausOrder encode by state; consider leaner persistence projections for hot writes if state tags show packed/closed docs dominate the tail.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[pkg-pr-new]

Open in StackBlitz

@effect-app/cli

npm i https://pkg.pr.new/effect-app/libs/@effect-app/cli@862

effect-app

npm i https://pkg.pr.new/effect-app/libs/effect-app@862

@effect-app/eslint-codegen-model

npm i https://pkg.pr.new/effect-app/libs/@effect-app/eslint-codegen-model@862

@effect-app/eslint-shared-config

npm i https://pkg.pr.new/effect-app/libs/@effect-app/eslint-shared-config@862

@effect-app/infra

npm i https://pkg.pr.new/effect-app/libs/@effect-app/infra@862

@effect-app/vue

npm i https://pkg.pr.new/effect-app/libs/@effect-app/vue@862

@effect-app/vue-components

npm i https://pkg.pr.new/effect-app/libs/@effect-app/vue-components@862

commit: 66cdf37