fix(strict_provenance): gate update1 inside make() (target + key consistency)

[dimitri-yatsenko]

The 2.3 post-release audit of the make-integrity gates found update1() was a fully ungated write path under strict_provenance: inside make(), SideTable.update1({...}) silently mutated any table past the provenance boundary (empirically demonstrated — value changed 100→999 with no error), while the same write via insert is blocked. The asymmetry was unintended: the boundary is "write only to self (and Parts)," and update1 is a write.

Fix

update1 now runs the same two checks as insert, placed before the existence check so a provenance violation raises as such rather than as "no matching entry":

• assert_write_allowed(self, verb="update1 on") — target must be the make() target or one of its Parts. Blocked-update message: strict_provenance=True: update1 on '<t>' is not permitted inside make() for '<target>'. Only the target table and its Part tables may be written.
• assert_row_key_allowed(row, action="update") — key columns overlapping the current key must match: strict_provenance=True: updated row's '<k>'=<v> does not match the current make() key's '<k>'=<v>. Updates must be consistent with the key being populated.

Both gate functions gain wording parameters; the insert-path messages are byte-identical to before (spec-verbatim preserved). No-op outside make() / flag off — update1 outside strict mode is unchanged (pinned by test).

Tests (4 new; strict suite 12/12, test_update1 4/4, both green locally)

• blocked update1 on another table, with the target row verified untouched
• blocked key-mismatched update1 on self (raises the key-consistency error deterministically)
• allowed key-consistent update1 on self (corrective update within the boundary)
• default-off parity

Companion docs update (write-enforcement table rows + limits-list adjustments) rides in the datajoint-docs post-audit reconciliation PR. delete()/delete_quick() remain ungated by design and are being documented as a limit there, per the audit decision.