feat(program): approve a proposed program in the app

[mohammadp1001]

Closes #81 — the last of the 13.

Stacked on #94. Retarget as the chain merges.

Why

A draft the user never sees is a feature that does nothing. This is where the
proposal from #80 becomes a decision.

It shows what would change, not the YAML

The user is being asked to replace what they are following. The only question
they actually have is which exercises are new, which are gone, and which
moved. A raw file dump does not answer that.

The diff rules (the actual design problem)

lib/program-diff.ts — pure and unit-tested, because this is the fiddly part:

• Days pair by name before position. Resequencing a split must not read as
  removing every day and adding it back.
• Unmatched days then pair by position, so a rename reads as a rename rather
  than a simultaneous add and remove.
• Exercises compare by exerciseId, never by display name. The lift is the
  durable thing, not the label it happens to carry — renaming an exercise must
  not look like swapping it out.
• Dropped exercises are listed last within a day: "what am I losing?" only
  makes sense once you can see what you are getting.
• With no active program, everything is new — the honest reading for a user
  who has none.

The rationale comes before the diff

A list of changes with no reason behind it is not something anyone can judge.

Interaction

• The banner sits above the program and is server-rendered, so it is
  there on first paint rather than popping in. It is the one thing on that
  screen that needs an answer.
• Both actions take two taps. Neither replacing a training block nor
  throwing away a proposal should happen on a stray thumb.
• Approve and discard re-read the pending draft rather than trusting the id
  from the screen — the coach may have replaced it, or the user may have
  answered it in another tab. A stale id gets a 409 saying exactly that.

lib/db/program-proposal.ts assembles the proposal and its diff once, shared by
the page and the API route. Two implementations of a comparison this subtle
would drift.

Verified against the running app

• The proposal renders with its counts (1 new · 2 dropped · 1 changed) in
  both Persian and English, dir correct, no undefined/null in markup.
• Approving through the real route makes it active, clears isDraft, and
  retires the previous program rather than deleting it.
• Replaying the same approval returns 409.

Tests

lib/program-diff.test.ts (11): identical programs, added/removed/changed
exercises, comparison by id rather than name, reordered days not reported as
churn, a rename read as a rename, whole days added and dropped, a renamed
program, and the no-previous-program case.

app/api/programs/draft/route.test.ts (7): null when nothing waits, the
proposal returned with reasoning and diff, names resolved rather than null,
approve activating and clearing, discard leaving the active program alone, a
stale id refused with 409, and a non-draft program refused.

Full suite: 443 passed, 0 failed. tsc --noEmit and eslint clean.