fs-dialog: forward host <dialog> ARIA attributes via dialog.open() options (#67)

[Goosterhof]

Closes #67.

Summary

• dialog.open(component, props, options?) now accepts an optional third arg with host-level ARIA options that apply to the <dialog> element itself, not the inner component:

  dialog.open(ConfirmDialog, {title, message}, {
      ariaLabelledBy: 'confirm-title',
      ariaDescribedBy: 'confirm-message',
  });

• Three options exposed: ariaLabel, ariaLabelledBy, ariaDescribedBy. All optional, all independent. Omitting an option leaves the corresponding attribute off the <dialog> entirely (no empty-string attributes).
• Bumps fs-dialog 0.1.0 → 0.2.0. Additive, non-breaking — existing two-arg call sites continue to work unchanged.
• No inter-package consumers in the workspace (fs-dialog is a leaf in the dep graph), so no peer-range cascade.

Why

Surfaced in Back-to-code/ublgenie-app PR #167 (UBL-0027 Dialog a11y) where both ConfirmDialog and FormDialog had to walk closest('dialog') from a template ref to call setAttribute(...) consumer-side. Every fs-packages-adopting territory was on track to repeat that workaround — at least 6 territories on the war-room map. Issue #67 captured the pattern and asked for the wiring to live in fs-dialog as an option on dialog.open().

Implementation

• DialogOpenOptions interface added to the public surface (exported from index.ts).
• The three options are threaded into the h('dialog', {...}) call in open(). Vue skips undefined values, so omitted options leave attributes off the DOM.
• Inner-component prop forwarding is unchanged — the new options are kept strictly on the host vnode.

Tests (7 new)

• aria-label / aria-labelledby / aria-describedby each set independently with their dedicated string value
• All three set together — no cross-wiring between options
• Options omitted → none of the three attributes present on <dialog>
• Partial options (one provided, two omitted) → only the provided one set
• ARIA host options do not leak into the inner component's props (regression guard against accidental forwarding)

Acceptance (from #67)

• dialog.open() accepts host-level ARIA attributes alongside component props.
• Existing call sites that don't pass the new options continue to work unchanged.
• Once shipped, ublgenie's closest('dialog')?.setAttribute(...) calls in ConfirmDialog.vue / FormDialog.vue can be deleted in favor of passing ids through the open API.

CI Gates (all 8 verified locally)

• npm audit — 0 vulnerabilities
• npm run format:check — clean
• npm run lint — 0 warnings, 0 errors
• npm run build — fs-dialog rebuilt clean (1.45 kB ESM / 1.56 kB CJS)
• npm run typecheck — clean across all packages
• npm run lint:pkg — publint + attw clean across 10 packages
• npm run test:coverage — 45/45 passing, 100% coverage
• npm run test:mutation — 97.18% (≥ 90% threshold). Two surviving mutants are the documented unkillable equivalents (dialogId++ key format in key: line 87) — same baseline as before this PR; no new survivors introduced

Test plan

• CI run on PR
• After merge + npm publish: ublgenie deletes the closest('dialog')?.setAttribute(...) blocks in ConfirmDialog.vue / FormDialog.vue and replaces them with options on the dialog.open() call site

[cloudflare-workers-and-pages]

Deploying fs-packages with    Cloudflare Pages

Latest commit:	806b106
Status:	✅  Deploy successful!
Preview URL:	https://6a801fb3.fs-packages.pages.dev
Branch Preview URL:	https://feature-issue-67-dialog-aria.fs-packages.pages.dev

View logs