[yonilerner]

Implements the "Copy inherited arrays when editing project-level list
settings" TODO. Adds list-typed (string[]) field editing to
/pi-auto-settings with the inheritance behavior the TODO described:
when a project-level array hasn't been set yet, the first add copies
the inherited (defaults + user-global) entries before appending, so
the project file doesn't silently clobber the list the user sees.

• settings-store.ts: pure nextArrayForAppend / nextArrayForRemove
  helpers, modifySettingArrayField that composes them with partial-
  merge file IO, and a perProjectPath: null option on loadSettings
  for computing the inherited value (skip per-project layer).
• settings-ui.ts: kind: "stringList" descriptors for
  sensitivePathPatterns + all seven sandbox arrays; list-view editor
  with a add / d remove / enter remove / esc back. Shows an
  (inheriting N items — first edit copies them) hint when project
  layer is still inheriting.
• string[][] fields (extraSafeCommandPrefixes,
  sandbox.reviewOnlyCommandPrefixes) intentionally left for a
  follow-up — they need a 2D editor. Added a TODO entry.

Also:

• TODO.md: removed the three completed Configuration items (all already
  in docs/HISTORY.md); added a note at the top that completed items
  get removed and moved to HISTORY.
• docs/HISTORY.md: new "List-field editing with copy-on-first-add
  inheritance" section.

---

This is part 1 of 2 in a stack made with GitButler:

•  2  command prefix array editing #29
•  1  Implement copy-on-first-add for project-level list settings #20 👈

[yonilerner]

Im not sure this PR makes any sense actually. We dont even want list-fields in the settings UI, so if you make a project file, its sorta on you to base it off the global file..

[foxfirecodes]

I don't love these "step X" comments :ded: but something we should probably purge holistically from the repo at a later date

[foxfirecodes]

stressing