feat: make compaction markers always-on and remove the config knob

Compaction markers — the mechanism that writes a compaction boundary
into OpenCode's DB after historian publishes so OpenCode's
filterCompacted skips older messages on the transform input — has been
default-true since v0.9.0 and graduated from `experimental` to
top-level config in that release. There is no scenario where running
the plugin without markers gives a better outcome on long sessions:
without them, transform input grows linearly with session length and
performance falls off a cliff. The knob existed for early opt-out
during the experimental phase and is now pure noise that lets users
silently degrade themselves.

Removed everywhere it lives:
  - `MagicContextConfigSchema.compaction_markers` Zod field
  - `MagicContextConfig.compaction_markers` interface field
  - `experimentalCompactionMarkers` dep threaded through transform.ts,
    transform-compartment-phase.ts, compartment-runner-types.ts, and
    incremental/recomp/partial-recomp runners — the marker write/move
    paths now run unconditionally
  - Dashboard ConfigEditor field definition for "Compaction Markers"
  - JSON schema property
  - Generated `assets/magic-context.schema.json`
  - Test fixtures that explicitly passed `compaction_markers: true` or
    `compaction_markers: false` (`compaction_markers: false` was used
    in 16 e2e tests as noise-reduction; tests still pass with markers
    on because they don't assert anything about marker absence)

User config migration (doctor-opencode.ts):
  Doctor's existing migration block for `experimental.compaction_markers`
  → top-level was rewritten to DELETE both forms instead of moving the
  value. The flag lived in two places across releases:
    - `experimental.compaction_markers` (pre-v0.9.0)
    - top-level `compaction_markers` (v0.9.0–v0.21.3, default true)
  Both are now deprecated, and leaving either in the user's
  `magic-context.jsonc` produces a "compaction_markers is not allowed"
  Zod warning on plugin load. Doctor removes both.

  Uses the same comment-aware deletion pattern as the user_memories /
  pin_key_files migration blocks: comment-json's parse/stringify
  preserves user comments on a best-effort basis. The
  immediately-preceding "before-property" comment attached to the
  deleted key drops on delete (a comment-json structural limitation)
  but every other comment in the file survives — block comments,
  trailing comments on sibling keys, the `experimental` object header
  comment when it becomes empty, etc.

Verification:
  - plugin: 1431 tests pass, typecheck/lint/build clean (4.55 MB)
  - pi-plugin: 302 tests pass, typecheck/lint/build clean
  - cli: 74 tests pass (+2 documented skips), typecheck/lint/build clean
  - dashboard: tsc/build clean
  - JSON schema regenerated, no longer contains `compaction_markers`