Records preview tabs: edit protection is transient, so a just-saved record can still be replaced

## What

The records-region preview-tab protection added in #4154 is **transient**, not a promotion. #4154's description says it reaches the "same user-visible outcome as VS Code's promote-on-modify." It does not, and the difference is visible to users.

## The difference

VS Code **promotes** a preview tab permanently the moment you modify it — it stops being italic and is never replaced again.

Here, the tab is merely excluded from the consumption pool *while* `IsEditing()` is true:

```ts
(tab) => IsRecordsRegionTab(tab.configuration) && !this.tabContainerRef?.IsRecordTabEditing(tab.id)
```

`IsEditing()` reads `formHost.Form.EditMode`. Saving calls `SaveRecord(StopEditModeAfterSave)` → `EndEditMode()` → `EditMode = false`, so **the tab silently rejoins the pool** and the next plain click replaces it.

## User-visible consequence

1. Open record A in the records region (temporary tab).
2. Click Edit, change a field, Save.
3. Click the next row in the grid.
4. Record A's tab is replaced by record B.

No data is lost — A is saved. But the record you just finished working on disappears from your tabs, which is the opposite of what promote-on-modify gives you and not what the description leads you to expect.

## Cosmetic counterpart, fixed by the same change

While editing, the tab is still **unpinned**, so it renders italic — the shell's vocabulary for "temporary / replaceable" — even though it is currently protected. That is the inverse of the bug #4154 set out to fix, where record tabs were italic without the behavior.

Promoting on first edit resolves both: a promoted tab is pinned, so it is neither replaceable nor italic.

## Options

1. **Promote on first edit** (matches VS Code, fixes the italic inconsistency too). Pin the tab when `EditMode` first goes true rather than filtering it out of the pool.
2. **Keep the transient guard** and correct the description and `guides` wording so nobody expects promotion.

Found while reviewing #4154. Not blocking — no data loss either way.