Detail view: make Edit the primary CTA and move inline editing onto the field (hover pencil + double-click)

[os-zhuang]

Problem

On the record detail page the header exposes two competing edit entry points whose labels and hierarchy confuse users:

• `Edit fields` (i18n `detail.editFieldsInline`) — actually the inline-edit toggle: flips every field into an input, then becomes Save changes.
• `Edit` (i18n `detail.edit`) — opens the full form (ModalForm) for the whole record.

In the `RecordDetailView` synth / `page:header` path the overflow logic inverts the intended hierarchy: `Edit fields` renders as the visible button while the primary `Edit` gets buried in the `…` overflow (alongside Share / Delete). This is inconsistent with the monolithic `DetailView` header, where `Edit` is the primary CTA and inline is a secondary `outline` button.

Two parallel "edit" buttons is itself the smell — best-in-class products (Linear / Notion / Attio, and Salesforce for the enterprise-form case) collapse this to one clear model.

Proposal (Salesforce-style: one primary CTA + field-level inline edit)

1. `Edit` is the single primary CTA, always visible in the header (desktop + mobile).
2. Remove the standalone `Edit fields` / inline-edit toggle button from the header. The capability is not dropped — its trigger moves onto the fields themselves.
3. Inline editing is triggered from the field row:
   • hover a field → reveal a pencil affordance (discoverable primary path),
   • double-click a field → enter inline edit (power-user accelerator).
4. Keep a floating Save / Cancel bar while inline editing (reuse the existing inline-edit state machine).
5. Unify the `DetailView` header and the `RecordDetailView` synth (`page:header`) path so both behave identically.

Why not single-click

These are display fields containing selectable text / links (e.g. owner email). Single-click-to-edit conflicts with text selection and link activation, so double-click + hover-pencil is the right trigger on a read-oriented detail page (mirrors Salesforce/Airtable).

Guardrails to preserve

• Respect `userActions.edit` per field — don't blanket-enable/disable (ADR-0092 D4 / fix(plugin-form): managed 对象按 userActions.edit 逐字段 readonly 渲染，取消一刀切禁用（ADR-0092 D4） #2395).
• Computed / read-only fields show no edit affordance and must be stripped from the update payload (`sanitizeFormData`) to avoid `INVALID_FIELD`.
• Approval-locked records (`approval_status` = `pending`/`in_approval`) stay non-editable (existing `isLocked` handling).
• Mobile / touch has no hover or double-click → the header `Edit` button remains the fallback.

Acceptance criteria

• Header shows a single primary Edit button; no standalone Edit fields toggle.
• Hovering a field row reveals a pencil; double-clicking a field enters inline edit with a Save/Cancel bar.
• Read-only/computed fields expose no pencil and are not editable.
• Behaviour is identical in `DetailView` and `RecordDetailView` (page:header) paths.
• Verified in the browser against the showcase `Project` record.