test: give CommunityIssues its own issue row per run (#42062)

## Description

`Regression/Apps/CommunityIssues_Spec.ts` tests 8-10 create, update and
delete a row in the AForce Postgres datasource. That datasource is
shared by every run of this spec, and the row title was a fixed string,
so the rows collide across runs.

When a run fails after test 8, its row survives. On the next attempt
test 8 creates a second row with the same title, and
`table.SearchTable("Suggestion")` matches both of them - the leftover
row's title still contains "Suggestion" even after test 9 changed its
type to Troubleshooting. Test 9 then reads row 0 and updates whichever
row sorts first.

That is visible in the failure output. From release run 30085427662
(shard 1):

```
AssertionError: expected 'Adding Title Suggestion via script-updating title-updating title'
  to equal 'Adding Title Suggestion via script-updating title'
AssertionError: expected 'Suggestion' to equal 'Troubleshooting'
AssertionError: expected 'Troubleshooting' to equal 'Suggestion'
```

The spec appends `-updating title` exactly once per run, so a doubled
suffix can only come from test 9 updating a row that a previous run had
already updated.

This also explains why the spec fails *persistently* rather than
recovering: the leftover row is still there on the retry, so every
attempt inside the job fails the same way. In the last mining window
CommunityIssues was 2/2 persistent (zero recoveries).

## Change

Generate the issue title per run and search for it, so the table filter
matches only the row this run created:

- `issueTitle` is built once per run with a timestamp suffix.
- Test 8 types that title and searches for it instead of the generic
`"Suggestion"`.
- Test 9 asserts against `${issueTitle}-updating title`.

Test 10 is unchanged, and it gets stronger as a side effect:
`WaitForTableEmpty` now runs against a filter that only ever matched
this run's row, instead of one that could still match leftovers from
earlier runs.

One spec file, no product code, no shared support code.

## Verification note

There is no red-before repro for this. Reproducing it requires the
shared AForce table to already hold a leftover row, which is exactly the
state the change prevents. The evidence is the doubled-suffix string
above, which the spec's own code cannot produce in a single run. A green
Cypress run here demonstrates the change does not break the spec; it
does not by itself demonstrate the collision is gone.

## Automation

/ok-to-test tags="@tag.Widget"

Tracking: https://linear.app/appsmith/issue/APP-15705


<!-- This is an auto-generated comment: Cypress test results  -->
> [!TIP]
> 🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉
> Workflow run:
<https://github.com/appsmithorg/appsmith/actions/runs/30358510792>
> Commit: 5bf801d
> <a
href="https://internal.appsmith.com/app/cypress-dashboard/rundetails-65890b3c81d7400d08fa9ee5?branch=master&workflowId=30358510792&attempt=1"
target="_blank">Cypress dashboard</a>.
> Tags: `@tag.Widget`
> Spec:
> <hr>Tue, 28 Jul 2026 13:29:13 UTC
<!-- end of auto-generated comment: Cypress test results  -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Tests**
* Improved Community Issues regression coverage by generating unique
issue titles for each test run.
* Updated creation, search, and edit validations to consistently use the
generated titles.
* Reduced the risk of test conflicts and false failures caused by reused
issue names.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Author: wyattwalter

app/client/cypress/e2e/Regression/Apps/CommunityIssues_Spec.ts

@@ -31,6 +31,16 @@ describe(
     });
 
     let selectedRow: number;
+
+    // Tests 8-10 create, update and delete a row in the AForce Postgres
+    // datasource, which is shared by every run of this spec. A fixed title
+    // makes those rows collide: a run that fails after test 8 leaves a row
+    // behind, and the next attempt's search matches both the leftover and the
+    // new row, so test 9 updates whichever sorts first. Giving each run its own
+    // title keeps the search filter down to the single row this run created.
+    const issueTitle = `Adding Title Suggestion via script ${Date.now()}`;
+    const updatedIssueTitle = `${issueTitle}-updating title`;
+
     it("1. Import application json and validate headers", () => {
       homePage.NavigateToHome();
       homePage.ImportApp("CommunityIssuesExport.json");
@@ -314,9 +324,7 @@ describe(
       agHelper.AssertElementVisibility(locators._modal);
       agHelper.SelectFromDropDown("Suggestion", "t--modal-widget");
 
-      cy.get(locators._inputWidgetv1InDeployed)
-        .eq(3)
-        .type("Adding Title Suggestion via script");
+      cy.get(locators._inputWidgetv1InDeployed).eq(3).type(issueTitle);
       cy.get(locators._textAreainputWidgetv1InDeployed)
         .eq(1)
         .type("Adding Description Suggestion via script");
@@ -339,15 +347,15 @@ describe(
 
       agHelper.ClickButton("Confirm");
       agHelper.AssertElementAbsence(locators._toastMsg); //Making sure internal api doesnt throw error
-      table.SearchTable("Suggestion");
+      table.SearchTable(issueTitle);
       table.WaitUntilTableLoad(0, 0, "v2");
 
       table.ReadTableRowColumnData(0, 0, "v2", 4000).then((cellData) => {
         expect(cellData).to.be.equal("Suggestion");
       });
 
       table.ReadTableRowColumnData(0, 1, "v2").then((cellData) => {
-        expect(cellData).to.be.equal("Adding Title Suggestion via script");
+        expect(cellData).to.be.equal(issueTitle);
       });
     });
 
@@ -407,9 +415,7 @@ describe(
       });
 
       table.ReadTableRowColumnData(0, 1, "v2").then((cellData) => {
-        expect(cellData).to.be.equal(
-          "Adding Title Suggestion via script-updating title",
-        );
+        expect(cellData).to.be.equal(updatedIssueTitle);
       });
     });