A folder created with folders/AddUsingPath in a generic list has no list item — breaking its permissions returns 404

Symptom

You keep per-record data in a custom list and give every record its own folder with unique permissions (a common way to keep rows of one person readable only by HR and that person). The same helper has worked for years in document libraries. In the list:

POST /_api/web/folders/AddUsingPath(DecodedUrl='/sites/hr/Lists/Pay/12')   → 200
GET  /_api/web/GetFolderByServerRelativePath(DecodedUrl='/sites/hr/Lists/Pay/12')?$select=Exists   → { "Exists": true }
POST /_api/web/GetFolderByServerRelativePath(DecodedUrl='/sites/hr/Lists/Pay/12')/ListItemAllFields/breakroleinheritance(copyRoleAssignments=false,clearSubscopes=true)   → 404

The folder exists, yet every permission call on it fails.

Cause

In a generic list, web/folders/AddUsingPath creates the folder in the list's file system but does not create the list item that represents it:

GET …/GetFolderByServerRelativePath(DecodedUrl='/sites/hr/Lists/Pay/12')/ListItemAllFields?$select=Id
→ { "odata.null": true }

That is the OData v3 shape (a plain fetch with odata=nometadata). SPHttpClient in SPFx sends odata-version: 4.0, and then the same call returns { "@odata.context": "…$metadata#Edm.Null", "@odata.null": true } — with an @. Code that checks only odata.null will never see the naked folder from SPFx. Check both shapes, or decide by the presence of Id.

The folder shows up in /folders but not in /items. Permissions live on the list item (ListItemAllFields/roleassignments), so with no item there is nothing to break inheritance on — hence 404. In a document library the same method creates the item, which is why the trap stays hidden until a library pattern is reused in a list.

Fix

Create list folders as list items:

POST /_api/web/GetList(@l)/AddValidateUpdateItemUsingPath?@l='%2Fsites%2Fhr%2FLists%2FPay'
Content-Type: application/json;odata=nometadata

{
  "listItemCreateInfo": {
    "FolderPath": { "DecodedUrl": "/sites/hr/Lists/Pay" },
    "LeafName":   { "DecodedUrl": "12" },
    "UnderlyingObjectType": 1
  },
  "formValues": [ { "FieldName": "Title", "FieldValue": "12" } ],
  "bNewDocumentUpdate": false
}

This works even when the list has EnableFolderCreation: false — that setting only hides the New folder button in the UI.

Then make your helper check the item state, not existence:

1. After creating (or finding) the folder, read …/ListItemAllFields?$select=Id. odata.null or @odata.null = naked folder, an Id = a real item. Only then break inheritance. Measure that response with the same client and headers your code uses — a mock built from a console fetch hides the v4 shape.
2. If a naked folder already exists and is empty (?$select=ItemCount → 0), send it to the recycle bin (…/recycle()) and create it again as an item. If it is not empty, stop and report it — deleting a folder whose contents have no item would lose them.
3. Rows you add into the folder later (AddValidateUpdateItemUsingPath with UnderlyingObjectType: 0 and FolderPath set to the folder) inherit its permissions as usual.