[akhilp117]

Linear issue

Adds five decision-model lint rules as a temporary safety net while we build deterministic API checks in CI. All five are warn, so they show up in the lint comment but never fail the check. Each one should be removed once its deterministic check is enforced

Rules:

• api suite

  • returnsUnpaginatedList: A GET that returns a list that can keep growing without self.paginate(...). Covers lists nested in the response ({"data": [...]}), which the runtime pagination check in api/base.py misses because it only looks at top level lists
  • replacesMembershipWithList: A PUT/PATCH/POST list of IDs or members that replaces the whole stored set, so two overlapping edits overwrite each other. replayAccessMembers in organization_details.py is the example
  • returnsNumericIdAsInteger: A numeric ID returned as an integer instead of a string, per our API design rules
  • makesExistingInputStricter: An existing endpoint rejecting input it used to accept, or changing what an omitted field means: a field becomes required, a required field is added, new or tighter validation is added, or a default changes. These break callers like removing a field does, but the spec often doesn't change, so spec-diff checks can't catch them. New endpoints and new optional fields don't count

• security suite

  • looksUpObjectWithoutOrgScope: An object fetched by an ID from the request without filtering by the caller's organization or project, i.e, Project.objects.get(id=request.data["project_id"]). This is the first security rule in src/AGENTS.md, and no existing rule covers it. Lookups scoped by org or project, self.get_projects(), later has_project_access/check_object_permissions checks, and objects the endpoint base class resolved don't count

The api suite rules use threshold: 0.8, like the existing rules that had false positives. returnsNumericIdAsInteger keeps the default

Only reporting problems the PR adds

The linter shows the model only the lines a PR changed, never what they were before. So it couldn't tell new code from code that was already there. Touching a line next to an old integer ID got a comment, and the fix it suggested would break clients. The stricter input rule also couldn't see that required=False became required=True.

The api suite now also gets each file's git diff against the PR's base, with removed and added lines only, so unchanged code stays hidden as before. The workflow sets DECISION_MODEL_LINT_BASE: HEAD^1 for this; local runs get no diff unless you set it, ideally to git merge-base origin/master HEAD. The three design rules now answer INTRODUCED, PREEXISTING, or NONE, and only INTRODUCED is reported, so existing problems never get a comment. The stricter input rule compares the removed and added lines, which also lets it catch default changes again.

Tested in #129449 on six cases, with the old and new config. The old config made three mistakes: it flagged an existing integer ID on a reformatted line, flagged an integer ID in a file with none, and missed a field made required. The new config got all six right, for about 9% more input tokens.

[linear-code]

ENG-8873