chore: update Backend and Cli submodule refs (dev-2026-03-21)

Backend: username-based user lookup + permission introspection endpoint
Cli: implement all user commands (list, get, create, update, activate, deactivate, delete)

plans/harborforge-cli-go-plan.md

@@ -423,6 +423,54 @@ For leaf commands, this behaves the same as `--help`:
 
 ---
 
+## Permission Introspection Strategy
+
+The permission introspection strategy is now considered **decided**.
+
+### Normal command permission model
+
+For normal authenticated commands, the CLI should determine permissions through the authenticated user context derived from the token:
+
+1. resolve the current user from the token
+2. obtain the user's role
+3. obtain that role's permissions
+4. use those effective permissions to determine:
+   - `--help` output
+   - `--help-brief` output
+   - whether a subcommand is shown normally or marked `(not permitted)`
+
+This applies to normal command groups such as:
+- `user` (except `user create`)
+- `role`
+- `project`
+- `milestone`
+- `task`
+- `meeting`
+- `support`
+- `propose`
+- `monitor`
+
+### Special-flow exception: `hf user create`
+
+`hf user create` does **not** use the normal user-token permission model.
+It remains a special account-manager-token flow.
+
+That means:
+- normal permission introspection from the current user token should not be the gating mechanism for `hf user create`
+- `hf user create` help visibility should be handled independently of ordinary `user.write` capability
+
+### Backend implication
+
+Backend support for this strategy should ensure the CLI can derive:
+- current user identity
+- current user's role
+- current role permissions
+
+Whether this comes from one endpoint or multiple backend calls is an implementation detail.
+The strategy itself is settled: **token → user → role → permissions**.
+
+---
+
 ## Credential / Auth Rules
 
 ## Normal authenticated commands

plans/hf-cross-project-todo.md

@@ -11,7 +11,9 @@
 - [ ] Finalize MVP scope for first shipping version of `hf`
 - [ ] Confirm which existing backend routes can be reused vs which new routes are needed
 - [ ] Define canonical code-first lookup policy across all resources
-- [ ] Define permission introspection strategy for `--help` / `--help-brief`
+- [x] Define permission introspection strategy for `--help` / `--help-brief`
+  - settled as: token → current user → user role → role permissions
+  - `hf user create` remains a special account-manager-token flow and is not gated by ordinary user-token write permission
 - [ ] Define JSON output contract for CLI list/get commands
 - [ ] Define CLI exit code / stderr conventions
 - [ ] Define local plugin↔monitor communication protocol over `monitor_port`