feat: consistent user onboarding — reset-link invitations, canAccessPanel enforcement, MFA setup clarity (#1287)

feat: consistent user onboarding — reset-link invitations, canAccessPanel enforcement, MFA setup clarity (#1287)

* Initial plan

* feat: implement user onboarding and authentication consistency improvements

- Story 1+2: Replace plaintext password generation with Filament-native reset-link invitations
  - Updated UserPasswordResetService: remove generateAndEmail(), add sendResetLink() using AdminPasswordResetNotification
  - Updated UserResource form: hide password field on create, override afterCreate() to set approved_at and send invitation
  - Updated user:create artisan command: send reset link instead of outputting plaintext password
  - Deleted unused GeneratedPasswordNotification
- Story 3: Enforce approval, suspension, email verification in User::canAccessPanel()
  - canAccessPanel() now requires hasVerifiedEmail(), approved_at not null, suspended_at null, and ACCESS_ADMIN_PANEL permission
  - Updated UserFactory default to include approved_at=now() so existing tests continue to pass
- Story 5: Clarify MFA setup page with first-login guidance banner
- New tests:
  - tests/Filament/Authorization/PanelAccessEnforcementTest.php (12 tests covering all canAccessPanel() conditions)
  - tests/Console/CreateUserCommandTest.php (4 tests for the updated artisan command)
  - 3 new tests in UserResourceTest for invitation flow and approved_at
  - Fixed UserResourceTest pending_approval filter test to match new factory defaults

Agent-Logs-Url: https://github.com/metanull/inventory-app/sessions/a7b3da50-2fe8-4f6c-bca3-49756bedba34

Co-authored-by: metanull <20630081+metanull@users.noreply.github.com>

* refactor: address code review feedback on onboarding implementation

- Add clarifying comment to canAccessPanel() enforcement order
- Expand CreateUser.php placeholder password comment
- Add link-expiry note to sendInvitation modal description
- Simplify createFullyEligibleUser() helper to rely on factory defaults

Agent-Logs-Url: https://github.com/metanull/inventory-app/sessions/a7b3da50-2fe8-4f6c-bca3-49756bedba34

Co-authored-by: metanull <20630081+metanull@users.noreply.github.com>

* Fix: Failing CI checks

**Root Cause**
PR #1287 is blocked by `Mandatory Checks / Backend Tests (Unit)`, but the failure happens before tests run. `shivammathur/setup-php@v2` defaults `github-token` to the generated GitHub Actions token and writes it into Composer auth as `github-oauth.github.com`. Composer 2.9.7 then rejects the newer `ghs_...JWT...` token shape as invalid and prints the token in its validation error.

So this does not look like a new npm/composer vulnerability in the app dependencies. It is an external tooling interaction: `setup-php@v2` default token injection plus Composer’s token validation/error output plus GitHub’s newer token format.

**Fix Applied**
I disabled `setup-php`’s Composer GitHub-token injection anywhere this repo runs Composer without needing private Composer GitHub auth:

- continuous-integration.yml
- ci-build-test.yml
- build.yml
- action.yml

The npm GitHub Packages authentication remains separate via `NODE_AUTH_TOKEN`, so SPA package installs/publishing are not changed.

**Validation**
`get_errors` reports no new YAML errors in the edited CI workflows or composite action. Existing VS Code warnings in build.yml about dynamic `$GITHUB_ENV` values were already present and unrelated.

I also validated the changed workflow files with:

```powershell
npx --yes @action-validator/cli .github/workflows/continuous-integration.yml
npx --yes @action-validator/cli .github/workflows/ci-build-test.yml
npx --yes @action-validator/cli .github/workflows/build.yml