Task: Let a role's permission bundle be written

Add the write the Shape the role catalogue journey has never had. A role's permission list can be composed and saved in one operation, permission-gated, with the change reason and commentary every other write carries.

The junction row also gains the audit tail account_role already has, so a bundle change records who made it, when and why. The permission codes the role write and the permission CRUD check are seeded, so an administrator holding the documented code reaches them.

• iam.v1.roles.permissions.put replaces a role's bundle: the codes it names are the codes the role bundles once it returns. An addition is recorded with the caller's actor, the reason it gave and its commentary; a removal closes the row it removes.
• A removal has no reason of its own. The delete rule closes the row and leaves the tail the grant wrote, so a bundle reads as its live rows plus when each ended. Restamping the tail on removal would lose who granted the permission, which is the record the journey exists for.
• The write is refused without iam::roles:update, as a denied result carrying that code, before anything is read or written.
• An unknown permission code is refused as invalid, and no row is written.
• The junction row carries assigned_by, assigned_at, change_reason_code and change_commentary. The write records the reason it is given, and an empty reason becomes system.new_record, the same default every other write in the tree applies, so the store is never asked to invent one.
• The response carries the bundle as stored, so the screen that saved it reads back what it wrote instead of hoping.
• The codes the handlers check are the codes the seed defines: iam::roles:write for the generated role write, and iam::permissions:write and iam::permissions:delete for the permission CRUD.
• The caller's account id is resolved from the request's actor in one place, and a test proves a username resolves to its account. Every subject that needs the caller uses it; none parses the actor as a uuid.
• The shell and the HTTP gateway reach the same subject, and a role's bundle can be written from either.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

• The Commit column names a commit by its subject or by the branch tip, not by a hash, because this branch has been rebased three times onto origin/main and every rebase rewrites the hashes. A subject survives that, and the branch is PR #2484. Where a row names the branch tip it means the head of that pull request at the time of the measurement.
• The database was recreated a second time after the third rebase, so the two rows above are measured on the current base. The first run, on the first base, produced the same two figures.
• The IAM core suite failed on the rebased base until that recreate: origin/main added badge_code to ores_iam_tenant_statuses_tbl, and a database created before it answers column "badge_code" does not exist. Nothing in this branch was involved, and the suite passes on the recreated schema.
• All 22 local gates pass on the rebased base. The one failure the battery reported before the first rebase, projects/ores.ore/core/src/component_files.cmake, was stale on the older origin/main and has since been fixed there by its owner, so this branch no longer inherits it.
• Tangling the shell and HTTP recipes materialised projects/ores.shell/scripts/library/curve_sections/ and projects/ores.http/scripts/library/currencies/, whose recipe sources were committed and whose generated artefacts were not. curve_sections has since been committed on origin/main by its owner, and the duplicate the tangle wrote here was moved aside to build/audit/superseded/ before the rebase; currencies is still outstanding on main.
• The migration was not replayed against a database that predates the columns. A fresh database proves the create script, which is what the environment runs; the migration exists for the rollout, and its own docstring says so.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

A role's permission bundle can be written. iam.v1.roles.permissions.put takes the role and the complete bundle it should carry, checks iam::roles:update before it looks anything up, resolves every code before it writes anything, and answers with the codes as stored. The role-permission junction gained the audit tail account_role already had, so an added permission records who added it, when and why, and a removal closes the row while the grant's tail survives.

The caller resolution the write needs is fixed underneath it: the access subjects built the caller's account id by parsing the request's actor, which is a username, as a uuid, so iam.v1.roles.mine, .by-account, .assign, .revoke and both by-name subjects failed every live request. The service resolves the actor to their account in one place now, and a test proves a username resolves.

Three permission codes the handlers check are seeded (iam::roles:write, iam::permissions:write, iam::permissions:delete); twelve remain, and they are filed as a capture with the gate that would protect them once seeded.

Evidence: the database was recreated from the changed create scripts (555 permissions, 133 role-permission assignments); the five IAM suites pass, with seven new cases over the caller resolution and the bundle write; all 22 local gates pass on the rebased base, as does the ER diagram check, and CI reports 18 of 18 checks green on the pull request. Two review rounds ran before the PR, and every accepted finding is in the commits above.