Keep the Dag asset schedule the same shape for every caller

[henry3260]

closes: #73803

Stacked on #72862 — that PR's commit is included in this branch's diff; only the second commit belongs to this change.

Why

#72862 scopes GET /ui/next_run_assets/{dag_id} so events carries only the assets the caller may read, while asset_expression keeps a hidden slot for each unreadable one (#72864). AssetSchedule.tsx still derives both the total and its layout from events, so the Dag renders differently depending on who is looking at it.

For a Dag scheduled on assets A, B and C, a caller who may read only A sees:

• "0 of 1" instead of "0 of 3" — scheduledTotal is nextRunEvents.length.
• The single-asset layout instead of the popover, from the nextRunEvents.length === 1 branch.
• No asset schedule at all if none are readable — the !nextRunEvents.length branch falls back to timetableSummary, hiding that the Dag is asset triggered.

The popover contents are already correct: AssetExpression renders the hidden slots.

What

• NextRunAssetsResponse gains scheduling_asset_count: how many assets the Dag is scheduled on, counted before the readable filter narrows the query. It reveals nothing new — the redacted expression already carries one slot per asset.
• AssetSchedule.tsx uses it for scheduledTotal and for the two length-based branches. scheduledCount is unchanged: only readable, satisfied assets count as ready.

The count costs one extra query on an endpoint that renders once per Dag card, so assert_queries_count goes from 5 to 6. An alternative that avoids it — filtering unreadable rows in Python instead of SQL, taking the total from the unfiltered row count — would mean reworking #72862's approach; happy to switch if reviewers prefer that trade.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Claude Opus 5)

[pierrejeambrun]

Stale comment. Remove.

[pierrejeambrun]

Just one comment lgtm otherwise.

Need rebase.