The list mixed both kinds of configuration policy into one table, so the only
way to tell a shipped default from something the site had written was to read
the source column. Split them into two tables under their own headings.
The split is presentational only. Both tables render the same Edit and Delete
buttons gated on the same iseditable(p) rule, so a shipped policy is not
stranded behind a dead button the way it was when the buttons gated on
source === 'local'.
The spec counted exactly two disabled bindings, which the second table would
have broken while the behaviour it was guarding stayed correct. It now counts
Edit and Delete in pairs and asserts the two always agree, so adding a group
does not fail a test about button gating.
The shipped Configuration Policies rendered with working-looking Edit and
Delete buttons that did nothing. The API had already been widened to accept
shipped rows, but the buttons still carried :disabled on source !== local, so
the write was never sent and the change looked like it had never rolled.
Gate both buttons on the set the API actually accepts. The shipped badge stays:
it is provenance, not a lock, and it has to survive an edit so a site can still
tell a product-supplied row from one of its own.
Business Policies keep the local-only rule. Their API guard is unchanged and
no shipped Site Policy exists now, so the UI already matches.
Cover it with a spec, because the failure mode is a disabled attribute silently
disagreeing with a server guard - nothing errors, the button just does nothing.
