fix(BA-6955): grant kernel scheduling-history read alongside session read

[jopemachine]

Resolves #12999 (BA-6955)

Summary

POST /v2/scheduling-history/kernels/scoped/search (and the scopedKernelSchedulingHistories GQL query) is registered with auth_required and its action declares kernel:history as the entity being read, yet every non-superadmin caller — including the owner of the kernel — was rejected, because nothing ever granted kernel:history read:

• Migration a1c4e7b93f22 mirrored grants from entity_type = 'kernel', which nothing creates (kernels are reached through their owning session), so its SELECT matched zero rows. The empty result also masked the INSERT omitting the NOT NULL permission column.
• Runtime scope-role creation never included kernel:history either, so even a corrected backfill would have left users created afterwards without access.

Per the scope-chain model in proposals/BEP-1048/permission-check-scope-chain-examples.md §2, the subject of the check is the entity being read, with grants expected at ancestor scopes — so the fix supplies the grants rather than changing the action's entity type:

Half	Change	Precedent
Existing roles	Rewrite the (unreleased) migration to mirror session READ grants, carrying the source permission bits	21159a293dfb and the other migrate-to-rbac backfills
New roles	Grant kernel:history READ natively in the user owner, project admin, project member, and domain admin scope roles	*_admin_page entries in the same entity_operations() methods
Downgrade	Documented no-op — a mirror-based DELETE cannot tell backfilled rows from natively granted ones	f2b9a4c7e103

Reading a session is what carries kernel visibility (search_kernel.py authorizes via session), so kernel scheduling history follows the same boundary: it is exactly as visible as the session it belongs to, including domain-scoped session read grants.

Test plan

Verified on a live stack (kernel f53384a7… owned by user@lablup.com):

• Runtime half: a freshly created user's owner role receives kernel:history read (permission=1) natively, with no migration involved
• Backfill half: the upgrade SQL inserted 16 mirrored rows; re-running inserted 0 (idempotent, ON CONFLICT DO NOTHING)
• Owner passes the scoped query end-to-end (GQL v2, same adapter → action → RBAC path as REST)
• Negative control: deleting the kernel:history rows makes the same owner query fail with NotEnoughPermission; restoring them makes it pass — the check is enforced by exactly these rows
• Unit tests added for the four entity_operations() changes (tests/unit/manager/data/{user,group,domain}/test_types.py)
• Responses containing actual history rows — kernel scheduling-history rows are never written in this environment (session history recorded 4 rows for the same session while kernel history stayed empty); unrelated to authorization, tracked separately

🤖 Generated with Claude Code

[jopemachine]

Reopened with a reworked scope. The earlier close comment claimed the migration approach itself was wrong — re-verification against BEP-1048/permission-check-scope-chain-examples.md showed the opposite: the designed model checks the entity being read (kernel:history) at ancestor scopes, so the grant-seeding approach was correct and the EntityType.SESSION change attempted in #13003 violated the design.

What the earlier attempt was actually missing was the runtime half: scope roles created after the backfill also need the grant, following the *_admin_page precedent (f2b9a4c7e103 + native entity_operations() entries). This PR now carries both halves, plus the precedent-mandated no-op downgrade.

[jopemachine]

This will be addressed when we introduce virtual scopes and add the permission migration for kernel records. For now, I'll work around the issue by changing the entity type itself to session.

[jopemachine]

For the record: the design owner confirmed that kernel-entity permission records are intentionally kept empty, so this PR's grant-seeding approach (backfill + native role-creation grants) contradicts the intended data model and stays closed. The kernel-owner 403 is fixed in #12866 by authorizing the scoped search through session read (EntityType.SESSION), which needs no permission rows.