No e2e coverage for the strong approval ceremony on a destructive job

e2e/testdata/postgres/ob.yml.tmpl:37-42 と、e2e/server_test.go:397-400 にある既存のフローから始めます。現在の strong-approval ヘルパーを理解するために、e2e/apps/one-app-one-host.sh:54-63 と e2e/server_harness_test.go:385-400 を読みます。破壊的な fixture のカバレッジを追加して e2e スイートを実行します。誤ったトークンが拒否され、ジョブ名が受け入れられ、サマリーにジョブ名が含まれていれば完了です。

The problem

The strong approval ceremony — the typed confirmation guarding a destructive
or migration job — has no end-to-end coverage.

The only job run in the e2e suite is chore, which declares
data_effect: none (e2e/testdata/postgres/ob.yml.tmpl:37-42), driven with
y\n (e2e/server_test.go:397-400). That is the one-time class, not the
strong one. The unit test added in #171 covers ob approve --plan, and nothing
covers ob job run --plan or the inline ob job run <id> prompt against a
real binary.

Two e2e helpers still encode the pre-#171 rule and describe it as general:

• e2e/apps/one-app-one-host.sh:54-63 — approval_answer supplies the release
  ID when the class is strong.
• e2e/server_harness_test.go:385-400 — releaseIDRe extracts a release ID to
  feed the prompt.

Both are reached only from deploy helpers today, so nothing is broken. But a
destructive job added to the fixture later would fail confusingly against a
helper that looks like it handles the strong class in general.

Proposed change

Add a destructive manual job to an e2e fixture and drive the strong ceremony
against the real binary: the wrong token refused, the job name accepted, and
the summary naming the job. Then make the two helpers say which class they
handle, or teach them the job case.

Scope and safety

Test-only. No product change.

Found while auditing #171.