Widget does not refresh boards after identify

# Widget does not refresh boards after identify

## Summary

With Signed-in boards, verified widget identification succeeds and authenticated capabilities return canSubmit: true, but the widget keeps the anonymous board list. No board is selected, so Submit remains disabled.

## Details

### Problem

In Quackback v0.13.2, the widget does not refresh its available board list after a visitor is successfully identified.

This makes submission impossible when boards have View = Signed-in.

### Configuration

- Quackback v0.13.2

- Self-hosted

- Verified/HMAC widget identity enabled

- Portal access: Public

- Three feedback boards

- Board View: Signed-in

- Board Submit: Signed-in

- A default widget board is configured

### Reproduction

1. Load the widget from an embedding application.

2. /widget loads before the host sends the signed identity.

3. The initial widget loader therefore runs as an anonymous actor.

4. Because all boards have View = Signed-in, the initial board list is empty.

5. Send a valid signed identity with identify().

6. Identification succeeds.

7. Quackback refetches board capabilities using the authenticated Bearer session.

8. The authenticated capability response contains all three boards with canSubmit: true and canVote: true.

9. Fill in the feedback title and body.

### Actual behaviour

The Submit button remains disabled.

The authenticated user is correctly displayed by the widget and the authenticated board capability request succeeds.

However, the widget continues using the empty board list loaded before identification.

The configured default board therefore cannot be resolved and selectedBoardId remains empty.

The submission predicate remains false:

```ts

const canPost =

boardPermissions?.[selectedBoardId]?.canSubmit ?? false

const canSubmitForm =

title.trim() &&

selectedBoardId &&

(!needsEmail || email.trim()) &&

(canPost || needsEmail)

```

### Expected behaviour

When verified widget identity changes the effective actor, the widget should refresh all actor-dependent feedback data, including the available board list.

After successful identification:

1. Signed-in boards should become available.

2. The configured default board should be resolved against the refreshed list.

3. The default board should be selected.

4. Its authenticated canSubmit capability should be applied.

5. Submit should become enabled once the required fields are populated.

### Likely cause

The widget already refetches boardPermissions after identity/session changes, but it does not similarly refresh portalData.boards.

The form therefore combines an anonymous board inventory with an authenticated capability map.

### Suggested correction

After widget identity/session version changes:

- invalidate/refetch the actor-dependent board list;

- update the widget's available boards;

- resolve the configured default board against the refreshed list;

- preserve an explicit user board choice where appropriate.

Authorization should continue to be enforced through the normal server-computed board capabilities.

### Verified diagnostic result

A credentialed browser trace confirmed:

- widget identity succeeds;

- portal access returns { granted: true, reason: "public" };

- authenticated capability request contains all three board IDs;

- all three have canSubmit: true;

- title and body are populated;

- Submit remains disabled;

- no network or server error occurs.