fix: use ptype in GetNamedPermissionsForUser for subject index

[Arshil-Khan]

What happened

In GetNamedPermissionsForUser(ptype string, user string, domain ...string), the subject field index was looked up against hardcoded "p" instead of the passed ptype:

subIndex, err := e.GetFieldIndex("p", constant.SubjectIndex)

When a named policy definition has a column order differing from p (e.g. p2 = dom, sub, obj, act), subIndex was resolved based on p rather than ptype. Consequently:

1. GetNamedPermissionsForUser("p2", "alice") wrote the user into the domain column (index 0), returning [].
2. GetNamedPermissionsForUser("p2", "alice", "tenant1") wrote alice to index 0 and subsequently overwrote index 0 with tenant1. The subject column remained empty (wildcard), returning permissions for all users in that domain.

Fix

• Pass ptype instead of "p" into e.GetFieldIndex(ptype, constant.SubjectIndex) in GetNamedPermissionsForUser.
• Added unit test TestNamedPermissionsForUserWithDifferentColumnOrder in rbac_api_test.go verifying both no-domain and with-domain queries when the named policy has a custom column order.

Fixes #1759

Verification

• make test (go test -race -v ./...) passes.
• golangci-lint run passes with 0 issues.

[bitflicker64]

LGTM. Verified locally: the new test fails on master with exactly the two symptoms from #1759 (empty result without a domain, bob's row leaking with one) and passes with the one-line change. GetPermissionsForUser still goes through this function with "p", so the default path is unchanged.

Not for this PR, but worth a follow-up since #1759's reporter will likely hit it next: GetNamedImplicitPermissionsForUser has the same shape of bug. It resolves the domain index via ptype but matches the subject with a hardcoded rule[0], so on this PR's own model (p2 = dom, sub, obj, act) it returns [] for alice with or without a domain.

[bitflicker64]

Pre-existing, not blocking: the subIndex = 0 fallback here still swallows a missing <ptype>_sub token (with no SetFieldIndex call), while the domain lookup a few lines down returns the error instead. Filtering on column 0 by accident would reproduce the same "other users' rows" symptom this PR fixes. Might be worth returning the error in a follow-up so the two lookups behave the same way.

[bitflicker64]

Nit: testGetNamedPermissionsForUser at the top of this file already wraps this call plus the Array2DEquals check, so the two assertions could each become a one-liner. Fine as is if you would rather keep the test self-contained.

[bitflicker64]

@hsluoyz this one is ready to merge from my side: one-line fix, and the new test fails on master and passes with the change. The GetNamedImplicitPermissionsForUser note in my review can go in a separate PR.