Widget ignores new-post board targeting

# Widget ignores new-post board targeting

## Summary

The documented open({ view: "new-post", board }) command opens the widget but does not navigate to the submission form or select the requested board. The generic Home view is shown instead.

## Details

### Problem

In Quackback v0.13.2, the documented programmatic widget command for opening a new post form does not work.

For example:

```ts

open({

view: 'new-post',

board: 'bug-reports',

})

```

opens the widget, but does not open the new-post form and does not select the requested board.

### Configuration

- Quackback v0.13.2

- Self-hosted

- Verified/HMAC widget identity

- User successfully identified before the command is exercised

### Reproduction

1. Initialise the Quackback widget.

2. Successfully identify the visitor.

3. Call:

```ts

open({

view: 'new-post',

board: 'bug-reports',

})

```

4. Inspect the resulting widget state.

### Actual behaviour

The widget opens the generic Home view.

The reproduced result contains the identified-user greeting and the generic "Suggest a feature" entry point. The new-post form is not visible and the requested board is not selected.

### Expected behaviour

Calling:

```ts

open({

view: 'new-post',

board: 'bug-reports',

})

```

should:

1. open the widget;

2. navigate directly to the feedback submission form;

3. expand the form;

4. resolve the supplied board slug;

5. preselect that board.

Calling open({ view: 'new-post' }) should open the form using normal default-board behaviour.

### Source-level behaviour

The SDK exposes and sends the view and board options, but the widget iframe's quackback:open handler does not appear to implement the corresponding new-post navigation.

The receiving handler supports views such as:

- home / overview

- changelog

- help

- chat

but there is no equivalent handling for new-post, and the supplied board value is not used to select a feedback board.

### Suggested correction

Handle the programmatic command as:

```text

view = new-post

↓

switch to Feedback

↓

expand submission form

↓

resolve optional board slug

↓

select requested board

```

The normal board authorization rules should still apply.

If the requested board does not exist or the actor cannot access it, the widget should fail safely rather than bypassing authorization.

### Suggested regression cases

#### Explicit board

open({ view: 'new-post', board: 'bug-reports' })

Expected:

- submission form visible;

- form expanded;

- Bug Reports selected.

#### No board

open({ view: 'new-post' })

Expected:

- submission form visible;

- configured/default board behaviour applies.

#### Inaccessible board

Expected:

- no authorization bypass;

- safe fallback or clear no-access behaviour.

### Verified diagnostic result

In a credentialed browser test:

- the widget user was successfully identified;

- the programmatic Report-a-bug action opened the widget;

- the resulting view remained Home;

- the new-post title/form was not visible;

- the requested board was not opened.